Decode once and compare exact strings
03Successful and failed comparisons use the actual decoded issuer value, not URL-equivalence guesses.
Separate error response declares https://other.example. It does not match the retained https://as.example/tenant. Reject the response and do not assume the intended server denied the user’s access.
Source for this drawing: RFC 9207 · Read RFC section 2.4 ↗
New to this? Start hereA quick picture + helpful background
A key is different from permission.
An app, a person, and a server have different roles. Follow who asks, who grants permission, and who checks the credential. A key in the drawing is an analogy, not a literal protocol field.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A trailing slash or changed letter is not an exact match.
- Supporting clients MUST extract present iss, decode application/x-www-form-urlencoded, and use simple string comparison against the expected issuer. With metadata, compare its issuer; otherwise use deployment-specific configuration.
- If the value differs, clients MUST reject the authorization response and MUST NOT proceed with the authorization grant. Do not normalize away a trailing slash, change case or choose a new token endpoint from the returned value.
- For mismatching error responses, clients MUST NOT assume the error originated at the intended server. The same comparison is required even though no code is present.
- Issuer correlation prevents mix-up in its stated threat model. It does not by itself authenticate a user, bind a code to a PKCE verifier or protect a tampered browser response.
This guide compares decoded strings. It does not compare percent-encoded spellings directly or imply that issuer matching alone is cryptographic response integrity.
Read the RFC section ↗