OIDC providers commonly distinguish between two distinct user fields:
preferred_username — a stable login handle (e.g. student01, j.smith)
name — the human display name (e.g. Anna Schmidt, Jane Smith)
Today the OAuth user-provisioning code in backend/open_webui/utils/oauth.py uses OAUTH_USERNAME_CLAIM for both the username AND the display name, forcing operators to make a Hobsons choice:
OAUTH_USERNAME_CLAIM set to
Username
Display name
preferred_username
✅student01
❌student01 (wrong)
name
❌Anna Schmidt (URL-unfriendly, contains spaces)
✅Anna Schmidt
Neither option is satisfactory for any non-trivial OIDC integration where the IdP returns proper structured profile data.
What
Add a new OAUTH_NAME_CLAIM env var, separate from OAUTH_USERNAME_CLAIM. Backwards-compatible: when unset, behaviour is unchanged (falls back to OAUTH_USERNAME_CLAIM).
# Recommended config for standards-compliant OIDC providers (Authentik,# Keycloak, Auth0, etc.):OAUTH_USERNAME_CLAIM:preferred_username # stable login handleOAUTH_NAME_CLAIM:name # full display name
Where
Two call sites in backend/open_webui/utils/oauth.py use the same logic:
L1646 — first-time signup: name = user_data.get(name_claim) ...
No DB migrations, no frontend changes, no breaking changes.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/open-webui/open-webui/pull/24535
**Author:** [@astoeffer](https://github.com/astoeffer)
**Created:** 5/10/2026
**Status:** ❌ Closed
**Base:** `dev` ← **Head:** `feat/oauth-name-claim`
---
### 📝 Commits (1)
- [`7f035ea`](https://github.com/open-webui/open-webui/commit/7f035ead009bdf0392846679aa72e375dc65fd4d) feat: separate OAUTH_NAME_CLAIM from OAUTH_USERNAME_CLAIM
### 📊 Changes
**2 files changed** (+29 additions, -6 deletions)
<details>
<summary>View changed files</summary>
📝 `backend/open_webui/config.py` (+11 -0)
📝 `backend/open_webui/utils/oauth.py` (+18 -6)
</details>
### 📄 Description
## Why
OIDC providers commonly distinguish between two distinct user fields:
- **`preferred_username`** — a stable login handle (e.g. `student01`, `j.smith`)
- **`name`** — the human display name (e.g. `Anna Schmidt`, `Jane Smith`)
Today the OAuth user-provisioning code in `backend/open_webui/utils/oauth.py` uses `OAUTH_USERNAME_CLAIM` for **both** the username AND the display name, forcing operators to make a Hobsons choice:
| `OAUTH_USERNAME_CLAIM` set to | Username | Display name |
|---|---|---|
| `preferred_username` | ✅ `student01` | ❌ `student01` (wrong) |
| `name` | ❌ `Anna Schmidt` (URL-unfriendly, contains spaces) | ✅ `Anna Schmidt` |
Neither option is satisfactory for any non-trivial OIDC integration where the IdP returns proper structured profile data.
## What
Add a new `OAUTH_NAME_CLAIM` env var, separate from `OAUTH_USERNAME_CLAIM`. Backwards-compatible: when unset, behaviour is unchanged (falls back to `OAUTH_USERNAME_CLAIM`).
```yaml
# Recommended config for standards-compliant OIDC providers (Authentik,
# Keycloak, Auth0, etc.):
OAUTH_USERNAME_CLAIM: preferred_username # stable login handle
OAUTH_NAME_CLAIM: name # full display name
```
## Where
Two call sites in `backend/open_webui/utils/oauth.py` use the same logic:
- **L1646** — first-time signup: `name = user_data.get(name_claim) ...`
- **L1700** — `OAUTH_UPDATE_NAME_ON_LOGIN` path: `new_name = user_data.get(name_claim) ...`
Both now resolve to `OAUTH_NAME_CLAIM or OAUTH_USERNAME_CLAIM`.
The "using email as name" warning was generalized to mention both env vars so operators can debug missing claims faster.
## Tested
Built locally + tested against Authentik 2024.10. With `OAUTH_NAME_CLAIM=name` set, OIDC provisioning now creates the user with:
- `username`: `student01` (from `preferred_username`)
- `name`: `Anna Schmidt` (from `name` claim)
Without `OAUTH_NAME_CLAIM` set, behaviour is byte-identical to current.
## Diff stats
```
backend/open_webui/config.py | 11 +++++++++++
backend/open_webui/utils/oauth.py | 24 ++++++++++++++++++------
2 files changed, 29 insertions(+), 6 deletions(-)
```
No DB migrations, no frontend changes, no breaking changes.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/24535
Author: @astoeffer
Created: 5/10/2026
Status: ❌ Closed
Base:
dev← Head:feat/oauth-name-claim📝 Commits (1)
7f035eafeat: separate OAUTH_NAME_CLAIM from OAUTH_USERNAME_CLAIM📊 Changes
2 files changed (+29 additions, -6 deletions)
View changed files
📝
backend/open_webui/config.py(+11 -0)📝
backend/open_webui/utils/oauth.py(+18 -6)📄 Description
Why
OIDC providers commonly distinguish between two distinct user fields:
preferred_username— a stable login handle (e.g.student01,j.smith)name— the human display name (e.g.Anna Schmidt,Jane Smith)Today the OAuth user-provisioning code in
backend/open_webui/utils/oauth.pyusesOAUTH_USERNAME_CLAIMfor both the username AND the display name, forcing operators to make a Hobsons choice:OAUTH_USERNAME_CLAIMset topreferred_usernamestudent01student01(wrong)nameAnna Schmidt(URL-unfriendly, contains spaces)Anna SchmidtNeither option is satisfactory for any non-trivial OIDC integration where the IdP returns proper structured profile data.
What
Add a new
OAUTH_NAME_CLAIMenv var, separate fromOAUTH_USERNAME_CLAIM. Backwards-compatible: when unset, behaviour is unchanged (falls back toOAUTH_USERNAME_CLAIM).Where
Two call sites in
backend/open_webui/utils/oauth.pyuse the same logic:name = user_data.get(name_claim) ...OAUTH_UPDATE_NAME_ON_LOGINpath:new_name = user_data.get(name_claim) ...Both now resolve to
OAUTH_NAME_CLAIM or OAUTH_USERNAME_CLAIM.The "using email as name" warning was generalized to mention both env vars so operators can debug missing claims faster.
Tested
Built locally + tested against Authentik 2024.10. With
OAUTH_NAME_CLAIM=nameset, OIDC provisioning now creates the user with:username:student01(frompreferred_username)name:Anna Schmidt(fromnameclaim)Without
OAUTH_NAME_CLAIMset, behaviour is byte-identical to current.Diff stats
No DB migrations, no frontend changes, no breaking changes.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.