GHSA-r95x-qfjj-fjj2: Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect
SummaryAn unauthenticated open redirect in Authlib's `OpenIDImplicitGrant` and `OpenIDHybridGrant` authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the `openid` scope.DetailsVulnerable code`OpenIDImplicitGrant.validate_authorization_request` in `authlib/oidc/core/grants/implicit.py`:`OpenIDHybridGrant.validate_authorization_request` in `authlib/oidc/core/grants/hybrid.py` shares the same pattern.Root causeBoth methods perform the `openid` scope presence check before delegating to `super().validate_authorization_request()`, which is where `AuthorizationEndpointMixin.validate_authorization_redirect_uri` validates the requested `redirect_uri` against the client's `check_redirect_uri(...)`. The `InvalidScopeError` thrown by the scope check therefore carries attacker-controlled `self.request.payload.redirect_uri`.`OAuth2Error.__call__` in `authlib/oauth2/base.py` renders any error with a non-empty `redirect_uri` as an HTTP 302:A malformed authorization request that selects `OpenIDImplicitGrant` or `OpenIDHybridGrant` and omits the `openid` scope is therefore redirected to a fully attacker-chosen URL.This is a variant of the issue fixed in commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) ("fix: redirecting to unvalidated `redirect_uri` on `UnsupportedResponseTypeError`") that was missed in the OIDC Implicit and Hybrid grants.PreconditionsThe server registers `OpenIDImplicitGrant` or `OpenIDHybridGrant` (standard OIDC Implicit or Hybrid flow support).The attacker's request uses a `response_type` that matches either grant: `id_token`, `id_token token`, `code id_token`, `code token`, or `code id_token token`.`scope` does not contain `openid`.Any `redirect_uri` value.No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid `client_id` are required. The scope check runs before any client lookup, so any `client_id` value (including nonexistent ones) reaches the vulnerable code path.PoCThe following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL:Server response:ImpactOpen redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider's domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker's page, lending the attacker's landing page the OP's reputation and potentially satisfying domain-allow-list controls that trust the OP.Phishing / credential harvesting leverage. The attacker's page can mimic the legitimate OP's consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack.RFC violation. RFC 6749 §4.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) §4.11 both state that an authorization server MUST NOT perform redirection to a `redirect_uri` that has not been validated against the client's registered URIs, even in error responses. The `state` parameter is echoed back, giving the attacker site a stable correlator.No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect.Affected deploymentsAny application using Authlib as an OIDC provider that registers `OpenIDImplicitGrant` and/or `OpenIDHybridGrant` — i.e. anyone supporting the Implicit flow or the Hybrid flow (`response_type=code id_token`, etc.) — is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue.Authorization servers that only register the plain `AuthorizationCodeGrant` (code flow, with or without PKCE and the `OpenIDCode` extension) are not affected by this specific variant: the code-flow grant validates `redirect_uri` before raising scope errors. If you were affected by the sibling issue fixed in `3be08468` (`UnsupportedResponseTypeError`), you should already be on `1.6.10` or later; this advisory is independent of that fix.Suggested fixThe attached `fix-oidc-open-redirect.patch` reorders each method to delegate to its super (or call `validate_code_authorization_request` for Hybrid) first, and then performs the `openid`-scope check with the validated `redirect_uri` variable.An equivalent transform is applied to `OpenIDHybridGrant.validate_authorization_request`, invoking `validate_code_authorization_request` first and only then checking `is_openid_scope`.Alternatively, inline a `client = query_client(request.payload.client_id)` + `client.check_redirect_uri(request.payload.redirect_uri)` guard before populating `redirect_uri` on the error — the pattern used in `3be08468`.The patch also adds regression tests analogous to `test_unsupported_response_type_does_not_redirect` from commit `3be08468`, asserting `rv.status_code == 400` and `rv.headers.get("Location") is None` for an unregistered `redirect_uri` with a non-`openid` scope.WorkaroundsNo clean server-side workaround exists short of patching. Partial mitigations:Unregister `OpenIDImplicitGrant` and `OpenIDHybridGrant` if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.)Front the `/authorize` endpoint with a reverse proxy rule that rejects requests containing both a `redirect_uri` parameter and a `scope` that does not include `openid` when `response_type` matches the vulnerable set. This is fragile and not recommended as a primary control.ReferencesRFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint)RFC 9700, §4.11 — Redirect URI validationOpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error ResponseAuthlib commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) — prior fix for the same class of issue in `UnsupportedResponseTypeError` (Authlib 1.6.10)Authlib source (by symbol; verified in commit `5d2e603e`):`OpenIDImplicitGrant.validate_authorization_request` — `authlib/oidc/core/grants/implicit.py``OpenIDHybridGrant.validate_authorization_request` — `authlib/oidc/core/grants/hybrid.py``OAuth2Error.__call__` — `authlib/oauth2/base.py` (renders errors with `redirect_uri` as HTTP 302)`AuthorizationEndpointMixin.validate_authorization_redirect_uri` — `authlib/oauth2/rfc6749/grants/base.py` (the validation that is bypassed)
CVSS v3.1: 6.1