Reject early and preserve redirect policy
04A failed push returns a direct error; checks that cannot run yet and redirect exceptions have precise limits.
Separate authenticated client, not the public example: the server MAY allow a previously unregistered callback within its configured permitted prefix. Authentication is established; this is not a general allow-any-URL rule.
Source for this drawing: RFC 9126 · Read RFC section 2.3 ↗
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.
Pushing a request early does not remove later validation or create an open redirect.
- PAR errors use token-endpoint-style HTTP/JSON responses, not browser error redirects. invalid_request can be the default for invalid redirect URIs; user-interaction errors such as consent_required are never returned by initial PAR processing.
- A server MAY defer a validation step that cannot be performed while pushing, but MUST perform it at the authorization endpoint. Policy changes may require revalidation even after an initially accepted push.
- Previously unregistered redirect URIs MUST only be accepted from authenticated clients. For clients with established authentication credentials, the server MAY relax exact matching at its discretion and apply restrictions; a public client_id alone does not qualify.
- POST is required; the endpoint can respond 405 for the wrong method, 413 for an excessive request size and 429 for exceeding its allowed request rate. Signed Request Object requirements must be enforced with 400 invalid_request if unmet.
The guide does not issue client credentials or implement client authentication. JWT client assertion users have specific audience rules in §2: issuer identifier SHOULD be used and server MUST accept issuer, token-endpoint URL or PAR-endpoint URL audiences. No real assertions are shown.
Read the RFC section ↗