Vaultwarden commit introduces SSO using OpenID Connect

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.

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

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).

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

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.

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

Yes, it does.

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.

https://www.heise.de/en/news/Password-manager-BSI-reports-cr...

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.

> 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...

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)

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)

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

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.

The logic is simple, Bitwarden is not there to detect intrusion attempts and safeguard your server so you gotta do it yourself, that's why its free.