Discover PAR and keep transaction safeguards
05Metadata signals capability and requirement; Request Objects and transaction checks remain separate protections.
A separate swapped-reference attempt returns another transaction’s state. The client’s exact stored-state comparison stops it; its retained PKCE verifier also remains bound to the original challenge.
Source for this drawing: RFC 9126 · Read RFC section 5 ↗
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.
PAR is a protected delivery path, not a replacement for the rest of OAuth security.
- Servers supporting PAR SHOULD publish pushed_authorization_request_endpoint in metadata. Its presence suffices to signal capability. Server and client require_pushed_authorization_requests are booleans defaulting to false if omitted.
- Server policy MAY require PAR globally or per client. When it does, an authorization request without a request_uri obtained from PAR is refused using invalid_request. Merely announcing an endpoint is not the same as requiring it.
- Clients MAY combine PAR with a JWT-Secured Authorization Request (JAR) Request Object. Its signing/encryption rules apply; authentication material remains separate. If credentials are established, the authenticated client_id MUST match the object’s client_id claim.
- RFC9126 recommends transaction-specific PKCE, state or an OIDC nonce against reference swapping. This example uses state and PKCE; later RFC9700 requires PKCE for public authorization-code clients. PAR does not replace CSRF, consent, issuer, audience or token validation checks.
Three reported, unverified errata 6711/7254/7410 address Request Object client_id wording and introductory examples. This guide does not treat those reports as approved changes or copy their ambiguous samples. Optional JAR is shown only as a decoded client-binding gate, not a full signed example or a ban on top-level client_id.
Read the RFC section ↗