Comment by cromka
7 hours ago
I selfhost vaultwarden for my use only. Can someone please explain it like I am 5 what's the use case of this new feature? Is it to log in to vaultwarden using an OpenID?
7 hours ago
I selfhost vaultwarden for my use only. Can someone please explain it like I am 5 what's the use case of this new feature? Is it to log in to vaultwarden using an OpenID?
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)
Same usecase for myself too. One of the biggest advantages for me is that it lets me setup a single and easily tested place for the users to reset passwords from too for when they inevitably forget or lose the post-it note. That, along with me using all the apps and not wanting to have to change 30 passwords for everything when something happens too.
I went a bit more complicated myself with Keycloak instead of Authentik, simply because I knew keycloak a little better but setting up SSO for all the stuff I run has definitely been worth it.
Yep same for me. I actually had been holding off on Vaultwarden precisely because it didn't have sso support. A single sign on is definitely better than the having the family try to remember a different password for every app.
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.