github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-08-24 23:22:58 -05:00
Code Issues 534 Packages Projects Releases 86 Wiki Activity

[GH-ISSUE #7206] Feature: Auto-provision new users on first SSO login (no manual admin invite required) #30134

New Issue
Closed
opened 2026-06-17 09:52:45 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-06-17 09:52:45 -05:00
Owner
Copy Link
Copy Source

Originally created by @David-Bratkov on GitHub (May 12, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7206

Summary

New users who successfully authenticate via SSO (Keycloak OIDC) for the first time are silently rejected and kicked back to the Vaultwarden login screen with no explanation. There is no self-service onboarding path — an admin must manually invite each user from the admin panel before SSO will work for them.

Current Behavior

  1. New user completes the full SSO flow (Vaultwarden email input → Keycloak login → redirect back)
  2. Keycloak authenticates them successfully
  3. Vaultwarden silently rejects them — no account exists, no error shown, no action taken
  4. User is returned to the login screen with empty fields
  5. No invite email is sent automatically
  6. Admin must manually go to /admin → Users → Invite for each new user before they can log in

Expected Behavior

When a user authenticates via SSO for the first time and no Vaultwarden account exists for their email:

Option A (preferred): Automatically send an invite email to the user's address (as returned by the IdP token) and show a page: "An invitation has been sent to your email. Click the link to finish setting up your vault."

Option B: Auto-create the account immediately and prompt the user to set their vault master password in-browser before proceeding.

Either option eliminates the need for per-user manual admin action when onboarding an organization via SSO.

Why This Matters

SSO is designed for organizational onboarding — the IdP is already the authority on who is allowed in. Requiring an admin to manually invite every user before SSO works defeats the main benefit of SSO for teams. Any user who passes IdP authentication should be considered trusted and eligible for auto-provisioning.

Environment

  • Vaultwarden: 1.36.0
  • IdP: Keycloak 26.x (OIDC), users sourced from LDAP
  • SSO_ONLY=true, SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=true, PKCE enabled
  • ~40 users in organization
Originally created by @David-Bratkov on GitHub (May 12, 2026). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7206 ## Summary New users who successfully authenticate via SSO (Keycloak OIDC) for the first time are silently rejected and kicked back to the Vaultwarden login screen with no explanation. There is no self-service onboarding path — an admin must manually invite each user from the admin panel before SSO will work for them. ## Current Behavior 1. New user completes the full SSO flow (Vaultwarden email input → Keycloak login → redirect back) 2. Keycloak authenticates them successfully 3. Vaultwarden silently rejects them — no account exists, no error shown, no action taken 4. User is returned to the login screen with empty fields 5. No invite email is sent automatically 6. Admin must manually go to `/admin` → Users → Invite for each new user before they can log in ## Expected Behavior When a user authenticates via SSO for the first time and no Vaultwarden account exists for their email: **Option A (preferred):** Automatically send an invite email to the user's address (as returned by the IdP token) and show a page: *"An invitation has been sent to your email. Click the link to finish setting up your vault."* **Option B:** Auto-create the account immediately and prompt the user to set their vault master password in-browser before proceeding. Either option eliminates the need for per-user manual admin action when onboarding an organization via SSO. ## Why This Matters SSO is designed for organizational onboarding — the IdP is already the authority on who is allowed in. Requiring an admin to manually invite every user before SSO works defeats the main benefit of SSO for teams. Any user who passes IdP authentication should be considered trusted and eligible for auto-provisioning. ## Environment - Vaultwarden: 1.36.0 - IdP: Keycloak 26.x (OIDC), users sourced from LDAP - `SSO_ONLY=true`, `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=true`, PKCE enabled - ~40 users in organization
GiteaMirror commented 2026-06-17 09:52:47 -05:00
Author
Owner
Copy Link
Copy Source

@stefan0xC commented on GitHub (May 12, 2026):

Can you share your Support String? Because I don't have that problem on my test instance.

<!-- gh-comment-id:4427713160 --> @stefan0xC commented on GitHub (May 12, 2026): Can you share your Support String? Because I don't have that problem on my test instance.
GiteaMirror commented 2026-06-17 09:52:47 -05:00
Author
Owner
Copy Link
Copy Source

@BlackDex commented on GitHub (May 14, 2026):

It looks more like a feature request to me though. Ill move it to Ideas

<!-- gh-comment-id:4451734355 --> @BlackDex commented on GitHub (May 14, 2026): It looks more like a feature request to me though. Ill move it to Ideas
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
wontfix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#30134