Evaluate Vaultwarden OIDC SSO (upstream support landed in 1.34) #122

Closed
opened 2026-08-17 17:49:55 -04:00 by mysticalsoap · 1 comment
Owner

The OIDC exclusion reasoning in Auth-and-Security.md predates Vaultwarden shipping SSO: upstream added OpenID Connect support in 1.34.0 (2025, SSO_ENABLED, marked experimental at release). Master password still does vault decryption — SSO replaces authentication only, so this is the same enforcement-point move the other OIDC clients got, not a key-escrow change.

To evaluate before committing:

  • Current maturity/caveats in release notes (it was experimental at launch)
  • Mobile app + browser-extension login flows through the SSO path
  • Whether the Authelia-gated /admin arrangement changes
  • Client policy: one_factor friend-tier like RxResume/Lychee, or two_factor given what it protects

Exclusion lists go stale — this is the periodic re-verify.

The OIDC exclusion reasoning in Auth-and-Security.md predates Vaultwarden shipping SSO: upstream added OpenID Connect support in 1.34.0 (2025, `SSO_ENABLED`, marked experimental at release). Master password still does vault decryption — SSO replaces *authentication* only, so this is the same enforcement-point move the other OIDC clients got, not a key-escrow change. To evaluate before committing: - Current maturity/caveats in release notes (it was experimental at launch) - Mobile app + browser-extension login flows through the SSO path - Whether the Authelia-gated `/admin` arrangement changes - Client policy: `one_factor` friend-tier like RxResume/Lychee, or `two_factor` given what it protects Exclusion lists go stale — this is the periodic re-verify.
Author
Owner

Evaluated 2026-09-20, declined on purpose.

Vaultwarden's SSO (1.34+) replaces authentication only; upstream's wiki states the master password is still required and not controlled by the identity provider, and there is no trusted-device encryption. So SSO would add the Authelia password on top of the master password rather than replace it.

That creates a bootstrap loop this setup can't have: on a fresh device with no cached vault, the SSO login needs the Authelia password, which lives in the vault. Today the vault depends on nothing but the master password and Vaultwarden's own second factor, and stays reachable when Authelia, LLDAP or the infra stack is down.

The usual SSO gains don't apply here: single-user vault with signups and invitations off, native TOTP/WebAuthn already, and since #294 the native login is under CrowdSec. Unlike the ForwardAuth-gated apps, Vaultwarden's API has to stay public for clients, so OIDC wouldn't shrink its surface either.

Re-verify only if Vaultwarden gains trusted-device encryption or Key Connector support.

Evaluated 2026-09-20, declined on purpose. Vaultwarden's SSO (1.34+) replaces authentication only; upstream's wiki states the master password is still required and not controlled by the identity provider, and there is no trusted-device encryption. So SSO would add the Authelia password on top of the master password rather than replace it. That creates a bootstrap loop this setup can't have: on a fresh device with no cached vault, the SSO login needs the Authelia password, which lives in the vault. Today the vault depends on nothing but the master password and Vaultwarden's own second factor, and stays reachable when Authelia, LLDAP or the infra stack is down. The usual SSO gains don't apply here: single-user vault with signups and invitations off, native TOTP/WebAuthn already, and since #294 the native login is under CrowdSec. Unlike the ForwardAuth-gated apps, Vaultwarden's API has to stay public for clients, so OIDC wouldn't shrink its surface either. Re-verify only if Vaultwarden gains trusted-device encryption or Key Connector support.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
mysticalsoap/docker#122
No description provided.