open-webui: Revoked users keep signing in via token exchange when roles are only in the ID token

Revoked users keep signing in via token exchange when roles are only in the ID token

Summary

The OAuth token exchange endpoint lets a user who already has a linked OAuth account swap a provider access token for an Open WebUI session. Since 0.11.1 it applies the OAuth role policy, but it only reads roles from the provider's userinfo response, and it only refuses a user when a roles claim is found. With an identity provider that sends roles only in the ID token (Microsoft Entra ID app roles are the common case), token exchange sees no roles and keeps the user's existing role, so a user whose provider role no longer satisfies the policy, and who is correctly refused at browser login, can still get a working session.

Preconditions

• ENABLE_OAUTH_TOKEN_EXCHANGE=true (default false).
• ENABLE_OAUTH_ROLE_MANAGEMENT=true (default false), with OAUTH_ALLOWED_ROLES (default user,admin) not containing *.
• The identity provider puts the roles claim only in the ID token and not in the userinfo response.
• The attacker already has an Open WebUI account linked to their provider identity, and can still obtain a valid access token from the provider (their provider account is active, only their role changed).

Deployments with either setting off, or whose provider returns roles in userinfo, are not affected.

Impact

A user the operator meant to lock out through the OAuth role policy keeps signing in through token exchange and keeps the role they held before, together with everything that role can reach. The attacker gains nothing beyond their previous access: an empty roles claim can neither grant admin nor change the role. Exploitation needs the non-default configuration above and a previously provisioned account. Browser SSO login is not affected and refuses the user as intended.

Fix

Fixed in 10d1cfe63, released in 0.11.4. Token exchange now also reads the roles claim from the exchanged token, and when role management is on and no roles claim can be read at all, it refuses the exchange.

Root cause

• Component: the OAuth token exchange endpoint (POST /api/v1/auths/oauth/{provider}/token/exchange) and the OAuth role policy it calls.
• Affected builds: 0.11.1 through 0.11.3, the releases that added the role policy to token exchange.

The role policy was written for browser login, where the ID token claims are merged into the user data before the policy runs, so "no roles claim" there means the provider genuinely sent none and keeping the current role is the documented behaviour. Token exchange never receives an ID token and builds the user data from userinfo alone, so for providers that only put roles in the ID token the policy always saw an empty claim and fell through to keeping the existing role instead of refusing.

Proof of concept

Reproduced on the 0.11.3 and 0.11.4 PyPI packages with a local OIDC provider that puts roles only in the ID token, ENABLE_OAUTH_TOKEN_EXCHANGE=true, ENABLE_OAUTH_ROLE_MANAGEMENT=true and an OAUTH_ALLOWED_ROLES list.

1. Sign in once through SSO while holding an allowed role, so the account is linked.
2. At the provider, change the user's role to one outside the allowed list.
3. Browser SSO login: refused with 403 on both versions.
4. Obtain an access token from the provider and send POST /api/v1/auths/oauth/{provider}/token/exchange with {"token": "<access token>"}.
5. On 0.11.3 the request returns 200 with a session token that works on GET /api/v1/auths/. On 0.11.4 it returns 403.

Control: a user still holding an allowed role is allowed on both versions.

Credits

• manus-pi: reported the role policy bypass on token exchange for providers that send roles only in the ID token.