Feature Request: Map OIDC group claims to Collections (post-authentication)

[DenisKoether]

Describe the feature

When using OIDC SSO (e.g. via Authentik), group information is already included in the ID token (groups claim). However, Vaultwarden currently ignores these claims entirely.

It would be useful to support optional mapping of OIDC group claims to Vaultwarden Collections (or organization memberships) after successful authentication.

---

Current behavior

• OIDC login works correctly
• User is created (if enabled)
• Group claims (e.g. groups) are ignored
• Collection membership must be managed manually inside Vaultwarden

---

Expected behavior

After a successful OIDC login:

• Vaultwarden reads group claims from the ID token (e.g. groups)
• A configurable mapping is applied, e.g.:

OIDC group "devops"   → Collection "DevOps"
OIDC group "finance"  → Collection "Finance"

• User is automatically assigned to the corresponding collections

This should be:

• Optional (disabled by default)
• Configurable (mapping table or environment config)
• Applied only after successful authentication

---

Use case

In setups with an external IdP like Authentik, user and group management is centralized.

Without this feature:

• group membership must be duplicated manually in Vaultwarden
• risk of inconsistencies increases
• onboarding/offboarding is more error-prone

With mapping:

• IdP remains the single source of truth
• Vaultwarden acts as a relying service
• administrative overhead is reduced

---

Security considerations

• No change to encryption model (zero-knowledge remains intact)
• Only affects authorization (collection membership), not cryptographic access
• Mapping is based on trusted IdP claims after successful authentication

---

Alternatives considered

• External scripts using the API (not ideal, adds complexity and maintenance overhead)
• Manual management (does not scale)

---

Additional context

This would align Vaultwarden better with common SSO + IdP patterns where group-based authorization is expected.

Even a minimal implementation (read-only mapping, no sync back) would already provide significant value.