SSO login returns token missing in keyring error

[Drblanco24]

Steps To Reproduce

1. Go to 'bitwarden.yourdomain.com
2. enter login info for you org
3. Select sign in with SSO
4. Enter Org ID
6. Error returns

Expected Result

SSO logs in user and requests master password

Actual Result

Error
There was an unexpected error during single sign-on.

The key {4991ac6e-606d-451d-ae14-72ddb5ddbc48} was not found in the key ring. For more information go to http://aka.ms/dataprotectionwarning

Screenshots or Videos

No response

Additional Context

Works for most users, specific to a handful with no discernable similarities.

Users that fail SSO are still able to login with regular username/password.

Githash Version

{"version":"2023.4.3","gitHash":"8d9ca424-dirty","server":null,"environment":

Environment Details

Kubernetes deployment with BW_ENABLE_SSO set to True

Database Image

No response

Issue-Link

#2480

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[djchateau]

Hey there,

There may be a small possibility of a misconfiguration of your SSO configuration as I am unable to reproduce this issue, but it has been escalated for further investigation. If you have more information that can help us, please add it below.

As we use GitHub issues as a place to track bugs and other development related issues. I would also suggest reaching out to our support for additional troubleshooting here to confirm any misconfiguration in settings aren't present.

Thanks!

[Drblanco24]

We were finally able to pinpoint how to recreate this issue:

1. Login with SSO < This works as expected
2. Close your tab without logging out
3. Reattempt SSO login
4. Error received stating "Token not found in keyring"

It seems the user's session token is persisting when the tab is closed instead of terminating it on the bitwarden side and allowing a new session to be authenticated.

There could be a setting we're missing? It appears the logout url field isnt yet supported.

[Drblanco24]

Final Update:

It seems we solved the problem. We're currently utilizing two geographically distinct instances of Bitwarden Unified in Kubernetes with a SQL backend.

In order to achieve a highly available setup, we had to manually replicate the /etc/bitwarden/data-protection directory to the persistent volumes at both locations. This allowed users who had accounts on one instance to login to the other instance without recreating their account.

Questions we have for the BW team really are:
What do the keys stored in the xml directory accomplish?
Are we compromising security through copying these? Is there a better way?
Do those keys rotate at any point or expire?
Is there a way to persist these into the database itself to ensure access is maintained?

[Rezkmike]

Im facing the same problem. User not able to login into Bitwarden via SSO.

Error :

System.Security.Cryptography.CryptographicException: The key {31b652d8-2824-4097-8b16-97c3a592e1b3} was not found in the key ring. For more information go to http://aka.ms/dataprotectionwarning

[Drblanco24]

Not sure what steps were taken previously, however, if you lost the keys in the directory I mentioned above, I believe we had to wipe our database to fix it. Those keys seem to be very important for users.

Would like for the bitwarden team to explain what these keys are for to help understand the best way to securely store them.

[Drblanco24]

@djchateau or any BW dev/engineer types here: just wondering if you had any insight on my last comment? We have been able to replicate the keys into the directory but it would be really valuable to understand what the keys are used for specifically and what triggers the keys to be created. We've noticed that keys have been created in August and November randomly. We originally deployed this in May.