mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-05-24 00:53:23 -05:00
[GH-ISSUE #6191] SSO with OIDC asks for Email, then Username, which it should already know #19138
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#19138
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Erudition on GitHub (Aug 17, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6191
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
v1.34.3-77008a91
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
nginx v2.12.3
Host/Server Operating System
Linux
Operating System Version
Docker/Portainer on Ubuntu Container in Proxmox
Clients
Web Vault
Client Version
No response
Steps To Reproduce
Expected Result
I expected to be already logged in, and just need to unlock my vault if needed. The login already happened via SSO.
At worst, I expected to have to hit a redundant "Log in with SSO" button that starts the OIDC process, redirects to Authentik, and bounces back to Vaultwarden letting it know who's already logged in.
Actual Result
I am asked to enter my email, even though that's provided by SSO, and then I'm asked to enter my username (unclearly referred to only as "SSO Identifier") even though that's implied by my email and also already known due to the SSO login... and then I'm asked to unlock my vault. Two extra steps
Logs
Screenshots or Videos
No response
Additional Context
Is there a URL I can launch instead of the base URL, to skip these steps and just use the email/username associated with the SSO user logged in?
@krparajuli commented on GitHub (Aug 25, 2025):
Is the username the exact same string as email in this case? Or is the username substring of the email? Attach screenshots for clarity please?
@Gauss23 commented on GitHub (Aug 25, 2025):
What env variables are you setting?
Here is the Authentik manual for Vaultwarden, which maybe helps: https://integrations.goauthentik.io/security/vaultwarden/#vaultwarden-configuration
@wangshug commented on GitHub (Aug 25, 2025):
I have the same question, login authentik after redirect I have to input my master password to unlock the Vaultwarden.
@ahlund commented on GitHub (Aug 26, 2025):
That is not the same question. Having to input the master password after SSO login is "intended behaviour". Check the WiKi (https://github.com/dani-garcia/vaultwarden/wiki/Enabling-SSO-support-using-OpenId-Connect)
@michaelbeaumont commented on GitHub (Aug 27, 2025):
Unfortunately Bitwarden requires an email to log you in. https://github.com/dani-garcia/vaultwarden/discussions/6204#discussioncomment-14161524
This seems to be something Authentik-specific. With Pocket ID for example I don't have to actually enter my SSO identifier. It's up to your SSO provider to handle logging you in.
@sistason commented on GitHub (Nov 24, 2025):
Clarification:
The Email is just in the frontend on login. It can be set as
user@example.com, after pressing the SSO button it gets overwritten with the email from the SSO for both registration or login. The email is initially sent to Vaultwarden, but dummy data is returned for that request, which is being ignored.This is afaik what the bugreport is about, to be able to remove this input-field or set it to "user@example.com" and make it hidden, ideally only when the "Login with SSO" Button exists.
Right now, we make SSO users type in their email-address, which gets discarded anyways. They don't know it, but SSO usually means you don't have to type in credentials anywhere except the SSO-Portal. It would be nice if Vaultwarden adheres to that security principle, besides making users type things they would not need to type :)
@michaelbeaumont commented on GitHub (Nov 24, 2025):
Sure but the challenge is that we're reusing Bitwarden frontends
@sistason commented on GitHub (Nov 25, 2025):
Ah, my bad then, I misunderstood that detail.
@rwjack commented on GitHub (Jan 3, 2026):
Have you tried just using:
https://your.domain/#/sso- orhttps://your.domain/#/sso?identifier=whatever@stefan0xC commented on GitHub (Jan 8, 2026):
Well, as far as I've looked into it, this is because SSO works a bit differently in Bitwarden and Vaultwarden because we currently only support one OIDC provider for all users while in Bitwarden this is configured per organization. So if you enter your mail address Bitwarden will do a lookup first; if you have a domain configured the second step (entering the sso identifier) can be skipped, whereas in Vaultwarden there are no domains so we can always skip directly to the configured SSO.
However, according to this comment the entered mail is also used to lookup the 2FA remember token.
And this is also true in Vaultwarden, so without even more modifications to the web-vault, this would break saving the second factor for 30 days. And I'm not sure what other ramifications there are if we were to make entering the email address optional.
@stefan0xC commented on GitHub (Jan 8, 2026):
That's actually what Bitwarden recommends as well. Though again with 2FA enabled this does not seem to remember the token. Personally I would prefer the remember email functionality.
@BoxBoxJason commented on GitHub (Jan 10, 2026):
Hey there, thanks for looking into this.
On the instances I manage, SSO is the only allowed sign-in method. Our users’ expectation when they click “Login with SSO” (based on many other SSO-configured apps they use) is simple:
What’s confusing here is that the UI asks users to type an email before the SSO flow starts. In practice that email is ignored by the local app and will be supplied by the SSO provider anyway, so asking for it is redundant and confusing. People try to type the email they “think” the account uses, or wonder whether they should use a different address — which creates unnecessary friction and support requests. (Requiring the master password after SSO is fine and expected.)
Would it be possible to adjust the sign-in/register workflow when SSO is configured so that:
These changes would match user expectations, reduce confusion, and cut down on support overhead.
@stefan0xC commented on GitHub (Jan 10, 2026):
Like I said that's probably not possible without modifying the web-vault too much and possibly breaking the login flow for other configurations. Since it's open source you can theoretically customize it however you want but I think we would only be interested in a PR that is beneficial for all use cases.
Also if you are fine with the above mentioned limitation I thought already confirmed that you could use
https://your.domain/#/sso?identifier=loginas a bookmark to skip entering the email address. Cf.So I don't think that any modifications are necessary if that's your main concern.
Oh, and for adding text I would recommend trying to customize your web-vault via CSS. E.g. I added a custom disclaimer on the login page of my testing instance like this
@steilerDev commented on GitHub (Jan 13, 2026):
This worked like a charm - for Authentik users (and I'm sure other providers allow this as well), you can put the URL into "Applications" -> "Vaultwarden" -> "Edit" -> "UI Settings" -> "Launch URL". This way, when the user hits the Vaultwarden tile on the SSO page, they get straight to the Master Password field.