RFC 9700 / ATTACKS & DEFENSES

Authorization server mix-up

A client using several authorization servers can be tricked into redeeming an honest server’s code at a malicious token endpoint.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 4.4 ↗

RFC 9700 · § 4.4DEFENSE

3 / 3

Abort instead of sending credentials onward.

A mismatched response must not trigger token exchange.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references

WHAT CHANGED

RFC 8252 § 8.10RFC 9700 § 4.4.2

The native-app BCP required distinct callbacks. The later security BCP describes response issuer identification and prefers it over relying solely on distinct callbacks.

Read the updated RFC section ↗

KEY POINT

Remember the issuer. Verify the response.

Clients using multiple authorization servers MUST prevent mix-up and bind the intended issuer to the browser transaction.
Use iss in the authorization response, including supported OIDC or JARM alternatives, and verify it as specified by RFC 9207. Abort a mismatch.
Distinct redirect URIs are a fallback when other options are unavailable; each must be bound to the expected issuer and verified.

DETAILS

Remembering only the authorization endpoint is insufficient: a malicious issuer can advertise an honest authorization endpoint with a malicious token endpoint. PKCE alone is not a mix-up defense.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy

All chapters in this RFC