SSO using OpenID Connect

[Timshel]

This is based on previous PR (#2787, #2449 and #3154) with work done by @pinpox, @m4w0lf, @Sheap, @bmunro-peralex, @tribut and others I probably missed sorry.

This PR add support for OpenId Connect to handle authentication to an external SSO.
This introduce another way to control who can use the vault without having to use invitation or an LDAP.

A master password is still required and not controlled by the SSO (depending on your point of view this might be a feature ;).

Bitwarden key connector is not supported and due to the license it's highly unlikely that it will ever be:

2.1 Commercial Module License. Subject to Your compliance with this Agreement, Bitwarden hereby grants to You a limited, non-exclusive, non-transferable, royalty-free license to use the Commercial Modules for the sole purposes of internal development and internal testing, and only in a non-production environment.

Usage

This should be agnostic to the SSO used as long as it supports client secret authentication and expose an OpenID Connect Discovery endpoint. (I'm testing it with Keycloak at the moment, a demo test stack is available README.md)

Added some documentation at the root of the project SSO.md that could be later moved to the wiki.

I made some additional modification in my main branch to allow for easier testing (modified Docker image to use prebuilt patched front-end).

On front-end modification, I made patched versions available at Timshel/oidc_web_builds. Two versions are available :

• One contains the change expected to be merged (named button); all change needs to be compatible with the non-sso version.
• Second one set #sso as the default redirect url.

Issues

As mentioned in the previous PR one of the main issue is the inability for the organization invitation to work with the SSO redirection. To fix it a patch to the front-end is needed.

⚠️⚠️ ⚠️ If you have issues or need help testing the PR ⚠️ ⚠️ ⚠️

Please open issues in Timshel/vaultwarden in order to keep the discussion here focused on merging this work.
Of course if you believe your issue is important mention this PR so a reference will be visible.

But please try to keep commenting in this PR to a minimum to keep it legible, the previous one has over 200 comments ...

[derfabianpeter]

Super happy to see this PR being worked on. We (ayedo.de) would be willing to offer a sponsoring to prioritize this PR if that helps! Just reach out.

[Timshel]

Just added a configuration example for Gitlab which might be one of easiest way to test this PR :).

[AkechiShiro]

Hi @Timshel, thanks for your amazing and prolonged work on this feature, is this PR close to be in a ready merge-able state or is there a lot of work left?
I see the latest commit is about documentation, so, all issues mentioned at the beginning were fixed in some way or another ? Or there are still issue to fix ?

[Timshel]

Mainly waiting for maintainer review/feedback now :).

[ruben-herold]

@Timshel thx for your work!!! Hope this will be integrated soon

[pellux-network]

Hoping this gets merged soon!

[AkechiShiro]

Tagging some maintainers for review on this PR, if they have the available time resource to do so @BlackDex @dani-garcia

EDIT: I don't understand the thumbs-down, because tagging maintainers doesn't mean they have time to handle the PR or review it, it's just a way to mention them, if they don't answer/go MIA, or whatever, feel free to fork on this PR and maintain your own forks, no one is entitled to do any work, they don't want to.

[BlackDex]

I do not have much time actually.

Also, I'm a bit puzzled with all the different SSO PR's.
And I am a bit hesitant to merge one if that for some reason could break the other or has a totally different way of working.
I'm not sure what to do here because i see people want something like this, but there are multiple ways of getting this working it looks like.

One way would be to create a semi-supported release branch which contains SSO support, but that could get messy keeping it up-to-date. What do you think @dani-garcia ?

[Timshel]

? As mentioned this is the continuation of the previous PRs, it all rely on openidconnect. All of those PR are based on the previous ones when the previous PR owner stopped maintaining it.

I can´t speak for the owner of previous PRs but I believe this make all the others redundant. You could probably close the previous one referencing this one and encourage their owner to reopen if something is missing.

Thanks @bmunro-peralex for closing his PR to make things more legible and of course for his work which is present in this PR :).

[xoxys]

Why not finally add at least one way to support OIDC? You can also flag it as preview feature or something like this to get feedback from the community, but not getting this feature into Vaultwarden after multiple PRs were provided by the community without a review or without getting merged for months until the authors then gave up feels wrong to me for an open source project.

[BlackDex]

Why not finally add at least one way to support OIDC? You can also flag it as preview feature or something like this to get feedback from the community, but not getting this feature into Vaultwarden after multiple PRs were provided by the community without a review or without getting merged for months until the authors then gave up feels wrong to me for an open source project.

Well, because One way could be a different way then the others, or could cause a lot of other changes needed to be done if they do not match, or maybe even could overlap and do something totally different. 49 FIles are changed, so I'm not going to be happy if there needs to be major rework done because of adding this feature which is not fully working/supported.

You have to keep in mind that this could break other code in some way. But as said before, i do not have much time to check and validate this. And this is a huge PR and a lot of testing needs to be done, and i this is not specifically on my prio list for now actually. That is why i mentioned a special branch, which builds this version with a different tag and not fully supported in terms of issues with the login from my side.

[Timshel]

Well, because One way could be a different way then the others, or could cause a lot of other changes needed to be done if they do not match, or maybe even could overlap and do something totally different.

@BlackDex I'll insist but there is no other way (At least not in the currently opened PRs). All those PR are based on the previous ones. They got more refined each time as someone picked-it up.

[tschuyebuhl]

is there any way one can help with testing? or anything that can be done to help get this merged?

[isaiah-v]

I've been watching the progress of this feature. I can't wait for it, but out of curiosity, how does decryption work with this feature? Is it still client side? How do you now decrypt without knowing the password?

[Timshel]

@isaiah-v as mentioned a master password is still required. There is no change on this point.

[Timshel]

@BlackDex thinking on it I don´t think the semi-supported branch is a good idea.

Main issue for people running this branch is that there might be some change in the migrations that might force to correct DB state manually. Even if it's not difficult (cf Timshel/vaultwarden#db-migration), integrating in a separate branch would not help with this.

Additionally unless you grant me commit rights it means that this would make it more complicated for me to support it and if you have no time for review I can't see how you would semi-support it.

It's important to note that the SSO_ENABLED config act as feature flag, the impact on the non sso version is quite low so merging this should have a low risk for the non sso users.

In the end if people are not running it at the moment it might be because they are waiting for an easier way to run this (but I made updates on main@Timshel/vaultwarden to make it easier) but I would expect it's mainly because they are waiting for it to be reviewed, a solution without any review would not be worth much ...

Since I'm running this myself I will maintain this branch/PR, and will continue to update main@Timshel/vaultwarden with anything I can think of to help people running it. As mentioned before if you have any question don't hesitate but please open it on Timshel/vaultwarden to prevent spamming here (of course mention this PR if you think your issue is important).

In my opinion the next step is for it to be reviewed and then integrated (maybe without being promoted at first).

[AkechiShiro]

I will definitely try to host the branch of your fork that contains sso-support and see if I run into any issues, I will report them on your repo @Timshel

[dandanthedev]

+1, please merge!

[griefie]

It seems that there is a lot of hesitation on investing time into reviewing this and i can understand this. However - the longer the delay the bigger the diff guys. The branch clearly works and simply needs a bit more love. Besides it already looks like a lot of work went into this and the older preceding branches. Why not make it a beta build? Even 2.0.0-beta? The closer it is to the main stream, the quicker will be the feedback and the improvement. Let's not forget this is open source, where ideas thrive and not corporate where ideas die ;)

[derfabianpeter]

We're still happy to sponsor this PR if it helps

[Timshel]

Rebased and added the @BlackDex suggestion in #3154 (comment) to make the SSO button visible when running the docker-compose.

[robere2]

Hi all,

I agree I want this PR merged, but it's not dead just waiting for a merge. You can view the fork here for a list of current issues, which may be the main blocker right now: https://github.com/Timshel/vaultwarden/issues
There's also issues on the "live" fork: https://github.com/Timshel/OIDCWarden

If you're looking to help OR the current status, check there! The latest update was last week, with the addition of organization syncing features.

[dani-garcia]

Locking for some time as this is getting way too off topic.

I've said it multiple times in other places before, there's no secret conspiracy on why these changes aren't merged, SSO is simply a massive new feature that is very hard to review and maintainers have very limited time, which is usually spent on ensuring that the server stays compatible with the latest apps (which is already hard enough), rather than adding new features that will only increase our maintenance burden.

This has always been the case since the first SSO PR, which was many years before I even started working with Bitwarden. Moreover, I'm not sure how Bitwarden would benefit from this not being merged, when Timshel/vaultwarden exists and is clearly usable today.

Ultimately, if you as a user want to use SSO or discuss how it's going, go to https://github.com/Timshel/vaultwarden/issues. That's where you'll have the most up to date information. This PR is only for code review of the change being merged. The only thing offtopic comments do is distract everyone, make review even more difficult and make users and maintainers more frustrated.

I will leave this locked for a day or two, and I hope people can understand that the point of a PRs comment section is to do code review and testing. For other topics, you can either go to Timshel/vaultwarden or open a separate discussion thread (please keep it civilized there though). If this continues I'll be forced to keep the PR locked, and that is just a bad outcome for everyone involved.

On a somwhat more positive note, I'm planning to dedicate one week of my summer vacation to test and review these changes to ensure they start moving towards a merge, if only to spare myself from the flood of unnecessary comments.

[Timshel]

Some comment on recent change, with recent client the 2FA email sending is triggered by the client.

The endpoint was already present but it relied on the email and master_password sent previously which are missing for the SSO flow. Additionally, the device_identifier was sent but unused, so replaced the logic to identity the user using it.

Issue with this is that for new device login, the device was saved only after passing the 2FA flow and the fact that is was missing was used to identify that it's a new device; but then the sending of the email was failing since the device was missing.
Made the modification to save the device at the start of the login flow, and to identify if the device is new, relied on checking if the create and update date are equal. This is a bit brittle since it relies on the fact that we always and only update the device after a successful login but though it was still better than adding a field just for this check.

---

Some comment on the latest release based on 1.34.1.

Rewrote the organization logic sync (not included in this PR) to allow to sync user membership and groups.
More details here README.md#organization-sync.
Additionally, deprecated/renamed some ENV variable (for the org sync feature), check README.md#deprecations

And since it had been some time since last release, I wanted to thank the sponsors and the TU Bergakademie Freiberg which allow me to continue to maintain this PR.
And of course all of this would not be possible without the maintainers of the project :).

Edit: and as always if you have some issue/question please open it there.

[Timshel]

⚠️ Hey
Had an issue with tests, some were not run against the correct database :(.
Which made me missed some issue with postgres and mysql, fixed postgres and working on fixing mysql, but wait for next release before updating.

Edit: 1.34.1-2 is building.
Additionally, I have to track some issue where the sso login flow sometime redirect to the org identifier screen, not sure if it's a cache issue since it's never triggered during the tests.

Edit2: Just a conf issue 😅
But realized I forgot to backport a commit for the web-vault.
So if you want to test org group sync 1.34.1-3, will be building soon.

[PinguDEV-original]

Is this working? Would love to see it