SSO with OIDC asks for Email, then Username, which it should already know

[Erudition]

Prerequisites

• I have searched the existing Closed AND Open Issues AND Discussions
• I have searched and read the documentation

Vaultwarden Support String

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.34.3-77008a91
• Web-vault version: v2025.7.2
• OS/Arch: linux/x86_64
• Running within a container: true (Base: Debian)
• Database type: SQLite
• Database version: 3.50.2
• Uses config.json: false
• Uses a reverse proxy: true
• IP Header check: true (X-Real-IP)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Websocket Check: true
• HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": null,
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "**************",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "***************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": true,
  "disable_icon_download": false,
  "domain": "*****://********************",
  "domain_origin": "*****://********************",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": false,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "10BitWorks",
  "invitations_allowed": false,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "",
  "org_events_enabled": true,
  "org_groups_enabled": true,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "purge_incomplete_sso_nonce": "0 20 0 * * *",
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": true,
  "signups_allowed": false,
  "signups_domains_whitelist": "**************",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "********************",
  "smtp_from_name": "10Bit Vault",
  "smtp_host": "**************",
  "smtp_password": "***",
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "**********************",
  "sso_allow_unknown_email_verification": true,
  "sso_audience_trusted": null,
  "sso_auth_only_not_session": false,
  "sso_authority": "*****://**********************************************",
  "sso_authorize_extra_params": "",
  "sso_callback_path": "*****://*************************************************",
  "sso_client_cache_expiration": 0,
  "sso_client_id": "****************************************",
  "sso_client_secret": "***",
  "sso_debug_tokens": false,
  "sso_enabled": true,
  "sso_master_password_policy": null,
  "sso_only": true,
  "sso_pkce": true,
  "sso_scopes": "email profile offline_access",
  "sso_signups_match_email": true,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

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

1. Set up Vaultwarden SSO with OIDC via environment variables (in my case, with Authentik)
2. Log in to SSO provider (e.g. Authentik)
3. Go from there to Vaultwarden Web Vault

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]

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]

What env variables are you setting?

Here is the Authentik manual for Vaultwarden, which maybe helps: https://integrations.goauthentik.io/security/vaultwarden/#vaultwarden-configuration

SSO_AUTHORITY=https://authentik.company/application/o/<application_slug>/
SSO_CLIENT_ID=<client_id>
SSO_CLIENT_SECRET=<client_secret>
SSO_SCOPES="openid email profile offline_access"
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false # Set to true to disable email+master password login and require SSO
SSO_SIGNUPS_MATCH_EMAIL=true # Match first SSO login to existing account by email

[wangshug]

I have the same question, login authentik after redirect I have to input my master password to unlock the Vaultwarden.

[ahlund]

I have the same question, login authentik after redirect I have to input my master password to unlock the Vaultwarden.

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]

I am asked to enter my email, even though that's provided by SSO

Unfortunately Bitwarden requires an email to log you in. #6204 (comment)

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

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]

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]

The Email is just in the frontend on login

Sure but the challenge is that we're reusing Bitwarden frontends

[sistason]

Ah, my bad then, I misunderstood that detail.

[rwjack]

Have you tried just using: https://your.domain/#/sso - or https://your.domain/#/sso?identifier=whatever

[stefan0xC]

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.

    // Set the email address in state. This is used in 2 places:
    // 1. On the web client, on the SSO component we need the email address to look up
    //    the org SSO identifier. The email address is passed via query param for the other clients.
    // 2. On all clients, after authentication on the originating client the SSO component
    //    will need to look up 2FA Remember token by email.

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]

Have you tried just using: https://your.domain/#/sso - or https://your.domain/#/sso?identifier=whatever

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]

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:

• If they’re already authenticated with the identity provider, they should be redirected straight in.
• If not, they should be prompted for their SSO credentials by the identity provider.

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:

• The email field is hidden (or clearly marked “optional / will be provided by your SSO provider”), and the “Login with SSO” button immediately initiates the SSO redirect; or
• At minimum, prefill or show a short explanation like “If you use SSO, your email will be provided by the identity provider — you don’t need to enter it here.”

These changes would match user expectations, reduce confusion, and cut down on support overhead.

[stefan0xC]

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=login as 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

#vw-disclaimer::before {
  content: "This is a non-production test environment.";
  display: block;
  margin: auto;
  margin-bottom: 1ex;
}