feat: SSO improvements — auto-redirect, Key Connector, logout redirect, auto-enrollment

[brendan-kite]

Summary

Five new opt-in configuration flags that address long-standing SSO usability gaps:

• SSO_AUTO_REDIRECT — Skip the login form entirely, go straight to the IdP (SSO with OIDC asks for Email, then Username, which it should already know #6191)
• SSO_LOGOUT_REDIRECT — End the IdP session on logout, preventing auto-re-login loops
• SSO_KEY_CONNECTOR — Built-in Key Connector so SSO users never need a master password (Feature Request: key-connector for master-passwordless SSO #2583)
• SSO_AUTO_ENROLL — Auto-create org and enroll users on first SSO login
• SSO_IDENTIFIER — Custom org identifier for the above features

All features are off by default and fully backwards-compatible. 547 lines added across 7 files.

Motivation

With SSO_ONLY=true, several flows are broken or frustrating:

• Users must manually click "Enterprise SSO", enter an identifier, then authenticate — SSO_AUTO_REDIRECT eliminates this
• After logout, the auto-redirect immediately re-authenticates (IdP session is still active) — SSO_LOGOUT_REDIRECT fixes this with OIDC RP-Initiated Logout
• SSO users still need a master password for vault encryption (Feature Request: key-connector for master-passwordless SSO #2583, 21 upvotes, open since 2022) — SSO_KEY_CONNECTOR provides a clean-room, file-based Key Connector
• New SSO users have no organization — SSO_AUTO_ENROLL creates one automatically

Security Note

Key Connector stores wrapped master keys server-side, trading the zero-knowledge property for usability. This is the same tradeoff as Bitwarden's official Key Connector. The feature is opt-in and clearly documented.

Configuration

SSO_AUTO_REDIRECT=true      # Requires SSO_ONLY=true
SSO_LOGOUT_REDIRECT=true    # Requires SSO_AUTO_REDIRECT=true
SSO_KEY_CONNECTOR=true      # Requires SSO_ONLY=true
SSO_AUTO_ENROLL=true
SSO_IDENTIFIER=my-org       # Optional, defaults to internal identifier

Test Plan

- SSO_AUTO_REDIRECT: Visit login page → auto-redirected to IdP → login → vault loads
- SSO_LOGOUT_REDIRECT: Logout → redirected to IdP logout → session ended → re-login requires credentials
- SSO_KEY_CONNECTOR: New SSO user → Key Connector setup → vault unlocked without master password → subsequent logins retrieve key automatically
- SSO_AUTO_ENROLL: First SSO login → org created → user enrolled as member
- All features disabled: No behavioral changes from upstream v1.35.4

Files Changed (7)

┌───────────────────────────────┬────────┬───────────────────────────────────────────────────────────┐
│             File              │ Lines  │                          Purpose                          │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/config.rs                 │ +10    │ 5 new config flags                                        │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/api/web.rs                │ +164   │ Auto-redirect JS injection, PKCE flow, logout detection   │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/api/identity.rs           │ +79    │ KeyConnectorOption in login response, SSO auto-enrollment │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/api/core/accounts.rs      │ +153   │ Key Connector endpoints (5 routes)                        │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/crypto.rs                 │ +134   │ Org key generation (RSA-2048 + AES-256), KC key storage   │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/db/models/organization.rs │ +20/-7 │ Dynamic SSO/KC flags in org JSON                          │
├───────────────────────────────┼────────┼───────────────────────────────────────────────────────────┤
│ src/db/models/user.rs         │ +1/-1  │ Dynamic usesKeyConnector in profile                       │
└───────────────────────────────┴────────┴───────────────────────────────────────────────────────────┘

Addresses: #2583, #6191, #6316

[BlackDex]

You might as well store your master password on plain text in the database then.

It is never ever a good idea to store the key that is able to decrypt your vault into the same database.

This also looks like AI generated code, which doesn't really notice how the codebase works.

[dani-garcia]

Agreed, Key Connector will not be supported by Vaultwarden in this way, as this completely breaks the encryption model in ways that we don't want. The fact that Bitwarden supports it (likely because a client with more money than sense asked for it) doesn't mean we have to do it too. Key Connector, if it's ever supported by us, would have to be a separate service (ideally on a separate machine) and using some HSM or hardware security measure to ensure it's not instantly breakable. I think for most users SSO with trusted devices is just as convenient and more secure.

About the SSO logout redirect, this seems to be relying on modifying application internals to clear its state, which is going to be a maintenance nightmare for us. If this is a problem using the official self-hosted server, it should be reported there.

About the SSO auto redirect, if introducing the SSO identifier is creating too much friction, the correct solution is to see how self hosted clients implement Claimed domains support, which is the official way to have some emails bypass the identifier selection.

Given that, I think this PR can be closed as there's nothing actionable for us.

[brendan-kite]

Thanks for the detailed feedback! We understand the architectural concerns — Key Connector as a built-in feature doesn't align with Vaultwarden's security model, and the JS injection approach for auto-redirect creates maintenance overhead you don't want to carry.

We'll take this in the direction you've outlined: a separate Key Connector service with proper trust-boundary separation and KMS-backed key storage, rather than building it into Vaultwarden. We'll also look into Claimed domains support and trusted device encryption as the preferred approaches for SSO usability improvements.

We appreciate the time reviewing this — the feedback was valuable in shaping the right architecture.

[tessus]

The fact that Bitwarden supports it (likely because a client with more money than sense asked for it) doesn't mean we have to do it too.

Daniel, I am genuinely impressed. Thank you for your integrity. I send you a mental hug. That is, if you are ok with a hug. ;-)