RFC 9207 / START HERE
OAuth response issuer, before the details
Issuer identification means naming the authorization server. RFC9207 adds the iss parameter to OAuth2.0 authorization responses.
An app remembers which authorization server it contacted. When the browser brings back a response, the app decodes iss and compares it to that saved server identifier before continuing.
The idea in one picture
Remember the expected server
Read the response issuer
Compare before continuing
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Apps that support several authorization servers can mix up where a code or token belongs. This RFC specifies the response field, exact comparison and support policies that help stop that mistake.
A familiar example
A calendar app supports two organizations. A returned code must belong to the server selected for this transaction, so the app checks its issuer before sending the code to the saved token endpoint. A matching issuer is not user authentication or a signature.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Remember the server before the browser returnsThe client retains an issuer and its endpoint mapping before processing a browser-carried response.→
- Read iss in success and error responsesA supporting server includes its issuer even when the authorization result is an error.→
- Decode once and compare exact stringsSuccessful and failed comparisons use the actual decoded issuer value, not URL-equivalence guesses.→
- Remember support for each serverCapability discovery and response policy distinguish required rejection from recommendations and local choices.→
- Keep identities and protections distinctUnique server identities and consistent issuer signals matter, while a plain parameter supplies no signature.→
This introduction explains RFC 9207 (2022). Read the original RFC ↗