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

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.