mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-18 09:52:56 -05:00
[GH-ISSUE #6413] "SSO Identifier" not returned from /admin/users API #35375
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @uedvt359 on GitHub (Oct 30, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6413
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
n.a.
Host/Server Operating System
Linux
Operating System Version
No response
Clients
CLI
Client Version
API
Steps To Reproduce
Expected Result
I expected the Admin API User's endpoint to return the full data available, including SSO parameters when SSO is used.
Actual Result
The "SSO Identifier" column of the table at /admin/users/overview is missing from the JSON API
Logs
Screenshots or Videos
No response
Additional Context
No response
@uedvt359 commented on GitHub (Oct 30, 2025):
I don't have the ability to test, but the following should do the trick (starting from commit
3cd3d33d00):@PetitGens commented on GitHub (Nov 12, 2025):
This exact code seems to already be on the main branch :2ee40d6105/src/api/admin.rs (L372)@uedvt359 commented on GitHub (Nov 25, 2025):
@PetitGens: you linked to #[get("/users/overview")], which is the html table. this code is missing from #[get("/users")], which is the json representation of the same data.
it seems, https://github.com/dani-garcia/vaultwarden/pull/6491 has been opened to fix this.
@maximilize commented on GitHub (Jun 22, 2026):
Confirming @uedvt359's diagnosis with exact locations: the SSO Identifier is set only on the HTML handler
#[get("/users/overview")](src/api/admin.rs:388), while the JSON handler#[get("/users")](src/api/admin.rs:354-369) iteratesfor (u, _) in usersand drops theOption<SsoUser>, sossoIdentifiernever reaches the API response.PR #6491 is the fix for this — it routes
/users,/users/overview,/users/by-mailand/users/<id>through a shared helper that emitsssoIdentifieron all four. Heads-up that it currently has merge conflicts againstmainand an open review request, so it still needs a rebase before it can land, but it does address this issue.