Read iss in success and error responses
02A supporting server includes its issuer even when the authorization result is an error.
Separate malformed issuer contains ?region=1. HTTPS alone is insufficient: issuer URLs must have neither a query nor a fragment. This is an identifier-format check, not permission to fetch an arbitrary response URL.
Source for this drawing: RFC 9207 · Read RFC section 2 ↗
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.
The response identifies its server independently of whether permission was granted.
- Servers supporting this specification MUST include iss in authorization responses, including error responses. iss is the issuer of the server creating the response.
- The issuer value MUST be an HTTPS URL with no query or fragment component. A path such as /tenant is allowed. Encode the value using the response’s application/x-www-form-urlencoded representation.
- When publishing RFC 8414 metadata, the issuer field MUST be identical to the iss value and authorization_response_iss_parameter_supported MUST be true. Servers MAY additionally convey their issuer by another mechanism.
- The error example assumes a valid client and callback. RFC 6749 §4.1.2.1 forbids automatic redirect to an invalid callback; adding iss does not permit such a redirect.
Location fragments shown inside a literal field are display-wrapped only. The response is not a JWT, a signature or an access token.
Read the RFC section ↗