Vaultwarden commit introduces SSO using OpenID Connect

SSO is really important in the "few tools, many users" case, but just as important in the "many tools, few users" case. I'm self hosting dozens of tools, and without SSO I'd have to set up username, password, TOTP and WebAuthn for each and every one of them, my 2FA app would be 90% my own services.

With SSO though, it's much simpler. I can just run an OIDC server and log into all my self-hosted services once, and I can use all of them. Vaultwarden is an exception to the rule though, as you can't really bootstrap that in the individual case.

Another use case I'm currently exploring is for sharing netflix/prime/disney+ passwords with roommates, partners and friends. They just sign in with their Google/Apple/whatever account and get access to the shared streaming provider passwords.

I support an installation for a couple hundred users. It's been working fine for several years now, including browser plugins and mobile clients. If the project goes under, it's easy to export everything and import into the official Bitwarden.

(Whose server I really don't enjoy, it's very enterprise-y and heavy on resources for no real reason I could find.)

As someone who manages the vault warden instance for a nonprofit with many volunteers but no fulltime employees I see this as a wonderful thing. Yes bitwarden has a nonprofit discount but no playing wack a mole with which of the 20+ volunteers are active at any moment to avoid getting a huge bill isn't worth it vs self hosting.

Started working (based on previous work already done) then maintaining the PR for my personal self-hosted stack.

Had then some fun adding roles/groups support (not yet merged).

SSO isn’t an enterprise feature, it is an access control and governance feature regardless of user population.

I'm hosting it for our team at a public institute, we are strongly supportive of OSS and have interest in keeping our data on premise.

Team of <10 though so hosting is trivial with NixOS. We also have almost no money available for purchasing software so official self-hosted bitwarden was not an option unfortunately (if we had money, that would've been the way to go).

I'm a user, not an expert on all this but: SSO is indeed meant for a corporate environment, not for personal use. And from what I saw, companies would rather pay for a simple SSO provider than use any self-hosted solution. That means you either use Google or Microsoft, nothing else.

LastPass is out of question due to the security issues in the past. I always advocate for Bitwarden but I'm not sure they can handle any kind of SSO yet. And Vaultwarden, being a fork of a not-so-famous-yet password vault (at least in the managers's world), is not a contender anywhere.

Vaultwarden is a lot easier to self host than Bitwarden

But like all community-made open source stuff, If you want to use it for "production" stuff you should invest in audits and contribute/fund development

If you're running on kubernetes, a simple network policy and blocking the container from using DNS will stop any compromised image from performing a data exfill.

I do this for most containers.

If the container must have web access in some form, setup a squid proxy and only whitelist safe and trusted domains that can't be exfilled to.

I've threat modeled this myself, and as I understand it the Bitwarden client side decrypts/encrypts everything locally. So even if backend was entirely compromised, it's never getting anything without the master password, and that's never sent across by the client. Then again, there's also the web interface.

Difference between work and personal. For personal, you’re right because there is nothing to bootstrap off of.

But in corporate it’s provisioned to a user account that exists first.

My personal bootstrap is two Yubikeys (for redundancy) that contains the password and 2FA for my Proton Pass. This plays the role of what IT would in a company with a user directory.

From this PR:

> A master password is still required and not controlled by the SSO

From the Bitwarden documentation[1]:

> Locking your vault will maintain vault data on the device, so unlocking your vault can be done offline. You will be required to enter your master password or PIN, or use biometrics, but won't need to use any active two-step login methods.

That really ought to quell the majority of the concerns IMO. Though for personal usage I use KeepassXC, because not having any remote authentication at all is even simpler than SSO.

[1]: https://bitwarden.com/help/vault-timeout/#vault-timeout-acti...

So you're going to play IT and duplicate all the groups and all the roles manually that already are maintained and automated for on/off-boarding? And not have them be auto-offboarded when they are let go? That introduces compliance risks and imo more problems than having SSO on your password manager. Yes, keep some master password for a rainy day if you have to, but otherwise, the more "dangerous" the thing the more it should be hooked up to SSO.

Well, without SSO, we (people making password managers for business) are in a weird position where we tell people "you won't have to remember passwords" then the first thing we do is to ask to remember a new password (the master password).

SSO also has the benefit that admin can impersonate another account, which is generally a good thing in a corporate environment (think of employee turn over, bus factor, etc)

Separate accounts for work and private. SSO for the work account is perfectly fine for me as a dev and a big advantage for the company. But yes, don't conflate the two use cases.

It's most useful for companies, where the goal is as much SSO as possible.

I administer it at work and now I won't have to invite a user manually, wait for them to accept the invite link via email, manually approve their account, and then assign it to groups (collections).

In other words one less thing to worry about during onboarding / offboarding.

Run a community space that uses its own SSO, and needs to share passwords for socials and the like.

Yep, exactly. I selfhost Vaultwarden and a bunch of other apps that my family also use. So I run Authentik, which lets them only have to worry about remembering one login, and they then have a little dashboard of all our apps, and can click to login to whatever they want. It's a pretty decent little system, and I'm happy I can now add Vaultwarden to it.

The bigger your users x applications number, the bigger the benefit. It make user management easy (e.g., you only have to manage users in one place instead of N)

My team self hosts multiple internal services, including vaultwarden.

For most of these we use our standard corporate OIDC provider to provide autentication and accounting, either onto a proxy or direct on the service, that passes the user through, the hosted service is either fine (just logs the user in its local access logs for the accounting part) because it's allowed for all our corporate users, or the service uses its own authorisation logic to allow or reject the users.

Some devices are just generic user/password on the device itself -- the authorisation there is that the group responsible for that device has to keep the credential secure. Any authenticated Corp user can access the login page, and that gets logged, but the authorisation is a simple user/password.

If the credential isn't secure (because people are terrible with security) then at least the attacker is logged, and has had to authorise access.

Some authentication is better. Our guacamole hosts for example are authenticated on proxy with OIDC, then passed through to the guacamole server which does its own authorisation based on its internal database (which itself is managed via a github approach - to add joe.bloggs@corp.com to the "Washington Servers" group you add his identity to the right part of the "groups.conf" file and when the PR is merged it applies across the estate within a minute or two). Then they can access all connections in "Washington", but "davey.jones@corp.com" isn't in that group, so can't.

Likewise our IPAM will create a user in the "readonly" group automatically (our policy is ip records are available to everyone in the company), but they then need moving into an elevated rights using IPAM tooling to allocate IP addresses.

Vaultwarden though we maintain separate user and password, we still have the OIDC front end, but it's completely ignored for another layer of authorisation. I'm about to go on leave so I won't be thinking too much about if this will help, but its good to have the option.

Depending on how many services you host, this is a huge deal for family and/or friends setups. I run around a dozen things that various family members and friends use, so being able to have one accout that they can log into anything with (including password change and reset) without me having to manually manage accounts makes the whole endeavour much more viable.

Creating, deleting, blocking accounts is the main one - you only do it once for a user and they get access to all your services. It also lets you do MFA and security checks on login (like on a new device) which can prevent break-ins even if your users use easily crackable passwords.

Access control -- can make it easy to add/sync users in Authentik using one username

Maybe if you deactiveer a users entra id that he cant access its vaultwarden vault anymore.

Can you expand the question a bit?