fix(oauth): keep OIDC identity scopes when audience is requested #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/oidc-scopes-with-audience"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
OIDC Core 1.0 §5.4 requires the standard scopes (openid, profile,
email, address, phone) and their conventional siblings (offline_access,
roles) to govern UserInfo claims independently of any audience
restriction. The /authorize handler was replacing the granted scopes
with the API-resource permission subset whenever
audiencewaspresent, leaving the access token with only resource permissions:
calls to /userinfo with that token then matched none of the
if scopeSet["profile"],if scopeSet["email"],if scope == "roles"guards in OIDCClaims/enrichClaimsWithRolesand returned
{sub}— breaking every relying party that mixesidentity and API access in a single login.
Make the audience branch take the union of client-level scopes
(client.Scopes whitelist) and API resource permissions
(client_resource_permissions). RFC 8707 §2.1 still applies — the
audience binds the token to its target API — but the OIDC contract
on
openidis preserved.OIDC Core 1.0 §5.4 requires the standard scopes (openid, profile, email, address, phone) and their conventional siblings (offline_access, roles) to govern UserInfo claims independently of any audience restriction. The /authorize handler was replacing the granted scopes with the API-resource permission subset whenever `audience` was present, leaving the access token with only resource permissions: calls to /userinfo with that token then matched none of the `if scopeSet["profile"]`, `if scopeSet["email"]`, `if scope == "roles"` guards in OIDCClaims/enrichClaimsWithRoles and returned `{sub}` — breaking every relying party that mixes identity and API access in a single login. Make the audience branch take the union of client-level scopes (client.Scopes whitelist) and API resource permissions (client_resource_permissions). RFC 8707 §2.1 still applies — the audience binds the token to its target API — but the OIDC contract on `openid` is preserved.