CVE-2026-114619: Authlib: OpenID implicit grant checks raw scope instead of allowed scope before issuing ID tokens

OpenIDImplicitGrant.validate_authorization_request() first runs the parent ImplicitGrant validation, which filters the requested scope through client.get_allowed_scope() and stores the result in request.scope. It then decides whether this is an OpenID request by checking the raw, client-supplied request.payload.scope instead of that filtered value. A client that is allowed profile but not openid can therefore request scope=openid profile, pass the check, and receive a signed ID token (with sub and profile claims) once the user consents. This happens even when Authlib’s built-in, scope-filtering BearerTokenGenerator is in use.

The tainted input is the authorization request’s scope parameter. The OAuth client fully controls it, and the client is the very party the scope restriction is meant to constrain. Any registered client can add openid to its request if it is permitted an id_token or id_token token response type and its allowed scopes exclude openid but include a claim-bearing scope such as profile.

Sibling paths treat the same client correctly, which suggests the raw-scope check is a bug rather than intended behaviour: