Push first, then open the browser
01The client sends request details directly to the authorization server; the browser later carries a reference to those details.
The client directs the browser to the server with client_id and request_uri. The request still needs normal authorization processing and user interaction.
Source for this drawing: RFC 9126 · Read RFC section 1.1 ↗
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 changes how an authorization request starts; it does not itself grant access.
- The PAR endpoint is an HTTPS HTTP API at the authorization server. The client sends authorization parameters directly in a POST; the user agent is not the transport for that push.
- After validation, the server returns a request_uri reference. The client directs the browser to the authorization endpoint with that reference and client_id.
- User authentication, consent where applicable and the rest of OAuth still follow. A successful PAR response contains neither an authorization code nor an access token.
PAR reduces exposure of request details in browser URLs, but does not hide all later OAuth messages or authenticate a public app merely because it knows client_id. Endpoints drawn on the same server perform different jobs.
Read the RFC section ↗