[PR #24535] [CLOSED] feat: separate OAUTH_NAME_CLAIM from OAUTH_USERNAME_CLAIM #115023

New Issue

GiteaMirror · 2026-05-18T15:56:59-05:00

GiteaMirror commented

2026-05-18 15:56:59 -05:00

📋 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)

7f035ea feat: 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.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 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.

_{🔄 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>

GiteaMirror added the pull-request label 2026-05-18 15:56:59 -05:00

GiteaMirror closed this issue

2026-05-18 15:57:02 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#115023