Fetch and display user profile photos from SSO Providers (Microsoft Entra / OIDC) in Admin Dashboards

[eduardomozart]

Is your feature request related to a problem? Please describe.
Currently, the Vaultwarden Admin Console (/admin) and the Members view provide a text-based list of users. While functional, it lacks the visual clarity provided by profile photos, especially in larger organizations where identifying users by name/email alone can be slower.

Since Vaultwarden now supports SSO (OIDC/SAML), many organizations already have high-quality user avatars stored in their Identity Providers (IdP) like Microsoft Entra (Office 365), Authentik, or Okta. Relying on Identicon is often not an option in private enterprise environments, leaving the admin interface looking sparse and making user management less intuitive.

Describe the solution you'd like
I propose that Vaultwarden fetch user profile photos during the SSO authentication flow and integrate them directly into the administrative views.

1. Administrative UI Enhancement:

• User Profile Header: Display the synchronized SSO photo in the top-right corner of the application window (User Profile/Account menu) to provide immediate visual confirmation of the logged-in identity.
• Admin Console (/admin): Update the "Users" table to replace the default Identicon with the fetched SSO avatar, allowing administrators to identify users visually at a glance.
• Organization Management (Admin Console > Members): Integrate the synced photo next to the user's name and email within the organization-specific member lists for better management and visual consistency across the platform.

2. SSO Provider Integration:

• OIDC Standard: Support the standard picture claim from the ID token.
• Microsoft Entra (Graph API): Implement a specific handler to fetch the binary photo data from https://graph.microsoft.com/v1.0/users/{id}/photo/$value using the Graph API, as Entra doesn't always provide a direct URL in the OIDC claim.

3. Local Storage & Proxy:

• Store the fetched image locally in the data/ directory (e.g., data/avatars/).
• Serve these images via a secure internal endpoint (e.g., /admin/api/avatar/{user_uuid}) to ensure they are only visible to authorized administrators.

4. Fallback Logic:

• If no SSO photo is available, fall back to the existing Identicon logic.

Additional context
This feature would significantly improve the "Enterprise" feel of Vaultwarden. Specifically for Microsoft environments:

• When a user logs in via SSO, Vaultwarden uses the access_token to ping the Graph API.
• The image is cached locally to reduce API calls and improve loading speeds in the /admin panel.
• This keeps user metadata entirely within the self-hosted environment, improving privacy.

Proposed Configuration Variables:

• SSO_SYNC_AVATAR=true (General toggle)
• SSO_MS_GRAPH_AVATAR=true (Enables the Graph API-specific fetcher)
• ADMIN_SHOW_AVATARS=true (Toggle for displaying photos in the admin interface)

[BlackDex]

From my point of view this is fully out of scope of this project.
The user management shouldn't be done via the admin in case of using SSO, but via the specific authentication provider.

This will only make the admin interface more complex.

[BlackDex]

I understood what you meant. But that doesn't change my opinion.

I'm not even sure we can adjust the web-vault icons, since SSO is kinda hacked in, since it is actually a Bitwarden Licensed feature.

[eduardomozart]

It shouldn't be too difficult. We need to change the DB schema to create an user picture column field, and if set and file exists, use it instead of the Identicon. Here's the current GLPI implementation: https://github.com/edgardmessias/glpi-singlesignon/blob/424485cfb5515340fa0f15494667caccefcd6d57/src/Provider.php#L1485-L1580

[BlackDex]

Again, I'm not aware of any way to adjust the icons of the web-vault in any way. They are always auto generated. But i could have missed a specific feature ofcourse.

[eduardomozart]

Since the web-vault is largely a pre-compiled React/Angular upstream asset, I understand the hesitation to introduce complex frontend modifications. Adding features that don't exist in the "upstream" Bitwarden code is difficult because Vaultwarden would have to patch the JavaScript files every time Bitwarden releases an update.

However, we could potentially approach this in two stages to keep it manageable:

• Admin Console (/admin): The /admin panel is much easier because it is built with Liquid/Handlebars templates directly in the Vaultwarden source code. Unlike the encrypted Web Vault, the Admin Panel is "owned" entirely by Vaultwarden and rendered directly by Vaultwarden's internal templates (not the encrypted web-vault); we have full control. Replacing Identicon here with a local endpoint (e.g., /admin/api/avatar/{uuid}) would be a 'clean' implementation and provide immediate value for user auditing.
• Web-Vault/Apps: Instead of rewriting the Web Vault, Vaultwarden can "trick" it. The Bitwarden client already makes requests to fetch profile data.
  • Endpoint: Vaultwarden could intercept the API call the Web Vault makes to retrieve user profile information.
  • Payload: In the JSON response for the user profile, there are fields for avatarColor. If we can't inject a customAvatarUrl because the Bitwarden frontend doesn't support that field yet, we are stuck with the "initials" icon.
  • Solution: I propose adding a small, persistent JavaScript injection to the index.html of the Web Vault (which Vaultwarden already modifies for branding). This script would:
    • Wait for the page to load.
    • Query the internal Vaultwarden API: /api/v1/user/avatar.
    • Locate the CSS selector for the top-right profile icon and the "Members" list icons.
    • Overwrite the src attribute or the background-image of those elements with the local SSO photo URL.

Avatar Endpoint (Backend)

The backend doesn't just "fetch" the photo once; it acts as a permanent host.

• Sync on Login: When a user logs in via SSO, the Rust backend uses the access_token to call the Microsoft Graph API. If a user changes their photo in Microsoft 365, it automatically updates in Vaultwarden the next time they log in.
• Binary Storage: The image is saved to data/avatars/{user_uuid}.png.
• Public/Private Route: Vaultwarden creates a route at /identity/avatar/{user_uuid}.png. This route should be protected so only a logged-in user can see the image, preventing profile photo leakage.

The goal isn't to turn Vaultwarden into a photo management tool, but simply to let the backend act as a proxy for the SSO provider's data—similar to how it already handles other directory synchronization tasks. We aren't managing the photo (there’s no "Upload" button in Vaultwarden). We are reflecting the state of the IdP. If we store the image as a blob or a local file, the 'complexity' stays mostly in a single background worker/job during the SSO callback.

[BlackDex]

We are not going to adjust the web-vault in this way ever.
We only adjust minimal stuff to get Vaultwarden working, everything else is out of scope period.

If Bitwarden is ever going to support such a feature then we could revisits this, but until that time it's not something i would put my time or effort into a purely cosmetic feature.