Security & Privacy

Vaultwarden SSO: Step-by-Step Setup & Troubleshooting

J
James Eriksson
··10 min read
Vaultwarden supports OIDC SSO since v1.35.0. Configure with Authentik, Keycloak, Entra ID in 15 min. Master password still required. Avoid common mistakes.
TL;DR
  • Vaultwarden supports SSO via OpenID Connect since v1.35.0; master password still required for vault decryption.
  • 12+ identity providers tested: Authentik, Keycloak, Entra ID, Google, GitLab, Pocket ID, and others.
  • Hybrid mode (SSO + password login) is safer than SSO-only for most teams; switch to SSO-only once IdP is reliable.
  • Configuration takes 15 minutes: register OIDC app at IdP, set three Vaultwarden env vars, test login flow.
  • Directory sync (LDAP, AD) not supported; users are created on first SSO login.

Vaultwarden supports SSO via OpenID Connect, available since version 1.35.0 in August 2025. Here's what you need to know: the feature works with Authentik, Keycloak, Entra ID, and 9 other providers. Your team still needs a master password to decrypt vault data client-side, so SSO handles login only, not passwordless access. This guide walks you through configuration and common mistakes.

Does Vaultwarden Support SSO?

Yes. OpenID Connect (OIDC) support landed in Vaultwarden v1.35.0 in August 2025. The protocol is open-source and production-ready, integrated into the core codebase, not a plugin.

SAML is not supported. If your team runs SAML-only (rare but happens with some corporate directories), you'll need a SAML-to-OIDC bridge like Keycloak or Authelia in front.

Here's the critical distinction: SSO handles authentication only. It does not replace the master password. Your users log in via your identity provider (Okta, Entra ID, Authentik, whatever you choose), and then Vaultwarden decrypts their vault using the master password stored client-side. If that sounds backwards to you, you're not alone--but it's the security model Vaultwarden chose, and it's worth understanding before you deploy.

How Vaultwarden SSO Works

OIDC is a wrapper around OAuth 2.0 designed for authentication (not authorization). When a user clicks "Sign in with SSO" on Vaultwarden's login page, here's the flow:

  1. Vaultwarden redirects to your identity provider.
  2. User authenticates (password, FIDO2, whatever your IdP supports).
  3. IdP returns a token with the user's email and name.
  4. Vaultwarden creates or logs in that user.
  5. User still enters their master password to unlock the vault locally.

The master password never touches Vaultwarden's servers. It's hashed on the client, and the client uses it to decrypt the vault data. SSO only governs who can log in; it doesn't govern what they can decrypt.

This is different from Bitwarden Enterprise, which can sync credentials and settings server-side without requiring a master password. Vaultwarden's model is simpler but gives you a clear boundary: authentication = centralized, decryption = local.

Supported Identity Providers: A Real Comparison

Vaultwarden's wiki documents 12 tested providers. Here are the ones worth considering:

ProviderTypeSetup DifficultyIdeal ForCommon Gotcha
AuthentikOpen sourceEasySelf-hosted, mid-size teamsEmail verification can get stuck; signing key selection is non-obvious
KeycloakOpen sourceMediumEnterprise, complex auth rulesHeavy resource footprint; overkill for 20 people
AutheliaOpen sourceMediumLightweight, single sign-on proxyFewer built-in features; better as a reverse proxy layer
Entra ID (Azure AD)CloudEasyMicrosoft-first companiesTenant ID and app secret must match exactly; MFA policies add friction
Google OAuthCloudVery easyHome lab, quick testingEmail domain checking can cause unexpected rejections
GitLabCloud/Self-hostedEasyDev-first teamsWorks only if GitLab is your team's primary identity source
Pocket IDOpen sourceVery easyMinimal self-hosted setupsBrand new (2024); smallest user base; good for tiny teams

If you have 20 people and no corporate directory, pick Authentik or Pocket ID. If you're running this at a company with AD or Entra ID, use that. If you're a home lab, use Google or GitLab. If you need LDAP sync, you'll need Keycloak or Authelia (and accept the complexity cost).

Step-by-Step Configuration

Configuration takes roughly 15 minutes for Authentik or Google, longer for enterprise directories. Here's the process:

Create an OIDC Application at Your Identity Provider

Log into your IdP (we'll use Authentik as the example). Create a new OIDC application with these details:

  • Redirect URI: Your Vaultwarden callback URL, typically your-domain/identity/connect/oidc-callback
  • Scopes: openid, profile, email (required)
  • Application type: Web application (confidential)

After creation, copy down:

  • Client ID (a unique identifier provided by your IdP)
  • Client Secret (a secure credential provided by your IdP)
  • OIDC Discovery/Issuer URL (the endpoint where Vaultwarden validates tokens)

Configure Vaultwarden Environment Variables

Add these to your docker-compose.yml or systemd environment:

SSO_ENABLED=true
SSO_CLIENT_ID=<your-client-id>
SSO_CLIENT_SECRET=<your-client-secret>
SSO_AUTHORITY=<your-idp-issuer-url>

Optional but useful:

  • SSO_SCOPES=openid profile email (if your IdP requires specific scopes)
  • SSO_CALLBACK_PATH=/identity/connect/oidc-callback (if you customize the callback path)
  • SSO_ORGANIZATION_INVITE_EXPIRES_HOURS=168 (controls invitation expiry)

Test the Login Flow

Restart Vaultwarden and visit your Vaultwarden domain. You should see a "Sign in with SSO" button below the master password field. Click it. You should be redirected to your IdP's login form. Log in with your test account. You should land back at Vaultwarden's vault with no master password prompt (unless this is your first login).

Enter Your Master Password

On first SSO login, Vaultwarden will prompt you to set a master password. You only set it once per account. Future logins via SSO remember you and ask for the master password as normal.

If nothing happens after you log in at the IdP, Vaultwarden's container logs will tell you why. Common reasons: redirect URI mismatch, missing scopes, untrusted issuer certificate (if self-hosted IdP without proper TLS).

Critical Gotchas & Troubleshooting

Redirect URI Exactness

The URL you register at your IdP must match Vaultwarden's callback URL character-for-character. Trailing slash, http vs. https, subdomain--all of it matters. If you see a "redirect_uri_mismatch" error, this is 90% of the time the culprit. Check:

  • Is your domain exactly the Vaultwarden domain you registered at your IdP?
  • Does your IdP list the exact callback path /identity/connect/oidc-callback? The path must match precisely.
  • If you're behind a reverse proxy, is the proxy passing the original hostname to Vaultwarden? Set the appropriate domain configuration in Vaultwarden's config.

Email Verification

Some IdPs (especially Authentik) send emails without verification. If Vaultwarden can't verify the email signature on login, it will reject the token. In Authentik, go to your application settings and disable email verification, or ensure your OIDC provider is configured to verify emails before issuing tokens. This is not a Vaultwarden bug; it's an IdP configuration choice.

Signing Key Selection

Authentik can use multiple signing keys. If Vaultwarden fails to verify the token signature, the key might have rotated. In Authentik, check that the application is using the same key for signing that Vaultwarden is validating. If unsure, delete the app and recreate it.

Master Password Confusion

Users often expect SSO to mean passwordless access. It doesn't. Explain upfront: "You log in with your company account (SSO), then you unlock your password vault with your master password." The master password is local; the company account is centralized. Both are necessary.

Token Expiration

Vaultwarden's OIDC session expires after 8 hours by default. If a user stays logged in longer, they'll need to re-enter their master password. This is fine for most teams. If you need longer sessions, adjust SSO_SESSION_EXPIRES_HOURS in the Vaultwarden config.

SSO vs. SSO-Only Mode: Which Should You Choose?

By default, Vaultwarden allows both SSO and password login. After you enable SSO, users can still log in with their email and password. This is hybrid mode, and it's the safer default. Here's why:

Hybrid mode pros:

  • Fallback if your IdP is down (users still log in with password)
  • Useful for emergency access if an account is locked out at the IdP
  • New users can set a password before SSO is ready

Hybrid mode cons:

  • Requires users to remember a password (defeats some SSO benefit)
  • Users might bypass SSO and use passwords instead (weaker control)

SSO-only mode: If you want to enforce SSO and disable password login entirely, set:

SSO_ONLY=true

In SSO-only mode, users cannot log in with passwords. They must use your IdP. This is stronger for security (centralized password policy, MFA enforcement). But it creates hard dependency on IdP uptime. If your Authentik or Keycloak goes down, nobody logs into Vaultwarden.

Recommendation: Use hybrid mode for the first month. Once you're confident your IdP is reliable, switch to SSO-only if your security policy requires it. For most teams, hybrid is the right tradeoff.

User Provisioning & Directory Sync: The Limitation

Vaultwarden doesn't support directory sync (LDAP, Entra ID sync, etc.). When you enable SSO, users are created on first login. If a user's OIDC token says their email is alice@company.com, Vaultwarden creates an account for alice@company.com.

This means:

  • You can't bulk-import users before SSO is live.
  • You can't pre-assign organizations or collections.
  • If someone leaves the company, their account stays in Vaultwarden until you manually delete it.

Workarounds:

  1. SSO_DEFAULT_ORG environment variable (if set): All new SSO users are auto-added to a default organization. Useful for small teams where everyone should be in one org.

  2. Manual enrollment: Create accounts by hand for power users, then they use SSO. Slower but works.

  3. Lightweight directory fallback: Use Authentik or Keycloak in front of Vaultwarden with their user-sync features. This adds complexity but gives you LDAP or AD sync.

If full directory sync is a hard requirement for your team, consider Bitwarden alternative solutions instead. Vaultwarden is self-hosted but requires manual user management.

What's Next: Managed Vaultwarden with SSO Built-In

Managing Vaultwarden SSO yourself means:

  • Keeping your IdP updated and secure (Keycloak, Authentik, or cloud service)
  • Monitoring token issuance and refresh
  • Handling redirect URI changes if you move domains
  • Troubleshooting email verification and signing keys

For a 20-person team, that's reasonable. For 100+ people across departments, it's full-time work.

Opsily's managed Vaultwarden hosting includes pre-configured SSO with Authentik, Keycloak, or Entra ID--no docker-compose needed, no env var debugging. We monitor the IdP, handle certificate renewals, and manage user provisioning. You focus on password management, not infrastructure.

Frequently Asked Questions

Does Vaultwarden SSO work with Active Directory? No, not directly. AD uses LDAP and Kerberos, not OIDC. Use Keycloak or Authelia to bridge AD to OIDC, then connect Vaultwarden to that bridge. This adds a layer but works reliably.

Do I still need a master password if I enable SSO? Yes. SSO handles login; master password handles decryption. Both are required.

What happens if my identity provider goes down? In SSO-only mode, nobody can log in. In hybrid mode, users still log in with their email and password. Plan for IdP downtime.

Can I use multiple identity providers? No, Vaultwarden supports one OIDC provider at a time. If you need multiple (e.g., Google for personal accounts, Entra ID for corporate), you'll need a proxy IdP that federates both.

How do I revoke a user's access if they leave? Delete the account in Vaultwarden's admin panel. Or disable the account at your IdP (in hybrid mode, this prevents SSO login but not password login). In SSO-only mode, disabling the IdP account blocks all access.

Does Vaultwarden support SAML? No, OIDC only. If your organization requires SAML, you'll need a SAML-to-OIDC bridge or switch to Bitwarden Enterprise.

What's the performance impact of SSO? Minimal. OIDC login adds ~500ms to the auth flow. Subsequent logins are cached, so it's not noticeable.

Can I use Keycloak for both Vaultwarden SSO and my company's other apps? Yes, that's Keycloak's entire purpose. It can serve as the identity provider for 10+ apps. Set it up once, reuse for everything.

The Bottom Line

Vaultwarden SSO is production-ready and worth setting up if you have a team of 5+. It simplifies login, centralizes access control, and integrates with most identity providers. The master password stays local, which sounds odd but makes sense once you see it work: login is centralized, decryption is local.

Start with Authentik or Pocket ID if you're self-hosting. Use Entra ID if you're already in Microsoft. Plan for hybrid mode first (SSO + password login fallback), then move to SSO-only once you're confident. And if managing the IdP yourself sounds like a headache, Opsily's managed Vaultwarden takes the load off.

Ready to deploy? Check out Opsily's managed Vaultwarden hosting to see how we handle SSO setup and ongoing operations.

Deploy Vaultwarden with SSO included
Opsily handles OIDC configuration, IdP monitoring, and certificate renewals—no docker-compose debugging needed.
Get Started Free

Ready to self-host your own apps?

One server. Multiple apps. No per-app fees.

Get started →