Solicitações de autorização enviadas (PAR)
Aprenda como as Solicitações de autorização enviadas (RFC 9126) transferem parâmetros de autorização para uma chamada segura de back-channel, melhorando a integridade e a confidencialidade em implementações avançadas de OAuth2.
Solicitações de autorização enviadas (PAR) é uma aula grátis de OAuth2 & OpenID Connect Deep Dive no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de OAuth2 & OpenID Connect Deep Dive, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de OAuth2 & OpenID Connect Deep Dive inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
The Front-Channel Problem
Normally authorization parameters travel in the browser URL to /authorize. They are visible, can be tampered with, and get long when requests are rich (claims, multiple resources). PAR moves them to a trusted back-channel.
What PAR Does
With Pushed Authorization Requests (RFC 9126), the client first POSTs all authorization parameters directly to a new pushed_authorization_request endpoint. The server stores them and returns a request_uri handle.
Step 1: Push the Request
The client authenticates and sends the parameters server-to-server.
POST /par HTTP/1.1
Host: op.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client creds>
response_type=code&client_id=app123
&scope=openid profile&redirect_uri=https://app/cb
&state=xyz&code_challenge=...&code_challenge_method=S256Step 2: Receive request_uri
The server validates and stores the request, returning a one-time request_uri plus an expiry.
{
"request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14",
"expires_in": 60
}Step 3: Redirect With the Handle
Now the browser redirect to /authorize carries only the client_id and the request_uri — nothing sensitive in the URL.
GET /authorize?client_id=app123
&request_uri=urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14Integrity and Confidentiality
Because parameters were pushed over an authenticated TLS channel, the user-agent cannot tamper with them, and they are not exposed in browser history, logs, or referrer headers. This raises assurance significantly.
Client Authentication at PAR
The PAR endpoint requires the client to authenticate (secret, mTLS, or private_key_jwt). This means the authorization request itself is tied to a verified client before the user ever sees the consent screen.
Short-Lived, One-Time Handles
The request_uri is short-lived (often 60 seconds) and intended for single use. After the authorization request consumes it, it cannot be replayed.
PAR and FAPI
PAR is a building block of FAPI 2.0 and financial-grade security profiles, where front-channel tampering must be eliminated. Many high-assurance deployments mandate PAR for all authorization requests.
Discovery Support
Providers advertise PAR via discovery metadata, including pushed_authorization_request_endpoint and optionally require_pushed_authorization_requests to enforce it.
{
"pushed_authorization_request_endpoint": "https://op.example.com/par",
"require_pushed_authorization_requests": true
}When to Use PAR
Adopt PAR for confidential clients in regulated or high-value contexts, when requests carry sensitive parameters, or when you want to guarantee request integrity. It pairs naturally with PKCE and mTLS-bound tokens.
Quick Check
Test your PAR knowledge.
Recap
Pushed Authorization Requests (RFC 9126) move authorization parameters to a back-channel.
- The client POSTs parameters to the PAR endpoint and gets a
request_uri. - The browser redirect carries only
client_id+request_uri. - This guarantees request integrity/confidentiality and authenticates the client up front.
- PAR is a cornerstone of FAPI-grade security.
Aprenda OAuth2 & OpenID Connect Deep Dive com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 12
- Aulas
- 48
Perguntas Frequentes
A aula “Solicitações de autorização enviadas (PAR)” é grátis?
Sim — o texto completo de “Solicitações de autorização enviadas (PAR)” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de OAuth2 & OpenID Connect Deep Dive, atualize para CoddyKit PRO. O curso de OAuth2 & OpenID Connect Deep Dive inclui 4 aulas no total.
O que vou aprender em “Solicitações de autorização enviadas (PAR)”?
Aprenda como as Solicitações de autorização enviadas (RFC 9126) transferem parâmetros de autorização para uma chamada segura de back-channel, melhorando a integridade e a confidencialidade em impleme… Você pratica OAuth2 & OpenID Connect Deep Dive com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar OAuth2 & OpenID Connect Deep Dive?
Nenhuma experiência prévia é necessária. OAuth2 & OpenID Connect Deep Dive no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Solicitações de autorização enviadas (PAR)”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de OAuth2 & OpenID Connect Deep Dive?
Sim. Cada aula de OAuth2 & OpenID Connect Deep Dive inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- FAPI e APIs de Nível Financeiro
- DPoP (Demonstração de Prova de Posse)
- Protocolo de Avaliação Contínua de Acesso (CAEP)
- Solicitações de autorização enviadas (PAR)