Visual RFC.
ALL RFCs / RFC 9207
Read the RFC ↗
RFC 9207 / AUTHORIZATION RESPONSE ISSUER

Remember the server before the browser returns

01

The client retains an issuer and its endpoint mapping before processing a browser-carried response.

DIAGRAMRead RFC section 1 ↗
RFC 9207 · § 1EXAMPLE
3 / 3
Remember the server before the browser returnsNormal authorization-code transaction: client stores issuer and its token endpoint, then authorization server redirects browser with code/state/iss, browser reaches client, client compares decoded issuer before a code request to the saved token endpoint. Other OAuth checks assumed satisfied; issuer check alone is not authorization or authentication.Remember the server · check before exchangesaved: https://as.example/tenantdecoded iss: https://as.example/tenantExact issuer match · other checks assumed satisfiedClient appToken endpointPOST code → saved token endpointcode=qa-code-Ahttps://as.example/tokenCode field only · other token-request fields omitted
03
Send the code only after the issuer comparison passes.

Decoded iss exactly matches the saved issuer. This simplified successful example then sends code qa-code-A to the saved token endpoint. Other OAuth checks are assumed satisfied, not replaced by this comparison.

Source for this drawing: RFC 9207 · Read RFC section 1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 6749 OAuth 2.0 RFC 3986 URI syntax RFC 9700 OAuth security

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

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

KEY POINT

Check who issued the response before sending a code onward.

  • OAuth lets one client use several authorization servers. A mix-up can send a code or token to the wrong recipient; single-server clients are not vulnerable to this particular attack class.
  • An issuer identifier names the authorization server. It is not the authorization endpoint, token endpoint, client ID or user identity. Supporting servers MUST provide their issuer identifier to clients.
  • RFC 9207 requires comparison to the issuer where the request was sent. Later RFC 9700 §4.4.2 explicitly requires storing that issuer for each request, bound to the user agent, and requires a mix-up defense for clients using two or more servers.
  • A matching issuer check permits the flow to continue only alongside its other checks: state, PKCE, callback policy, client authentication and token validation remain distinct.
DETAILS

The picture is one normal authorization-code transaction, not a full OAuth implementation or an attack trace. Later RFC 9700 guidance is labeled separately;RFC 9207 does not formally update RFC 6749 or RFC 9700.

Read the RFC section ↗

All chapters in RFC 9207

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗