Pushed Authorization Requests (PAR)
Dowiedz się, jak Pushed Authorization Requests (RFC 9126) przenoszą parametry autoryzacji do bezpiecznego wywołania kanałem tylnym, poprawiając integralność i poufność zaawansowanych wdrożeń OAuth2.
Pushed Authorization Requests (PAR) to bezpłatna lekcja OAuth2 & OpenID Connect Deep Dive na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej OAuth2 & OpenID Connect Deep Dive, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.
Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.
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.
Często zadawane pytania
Czy lekcja „Pushed Authorization Requests (PAR)” jest bezpłatna?
Tak — pełny tekst „Pushed Authorization Requests (PAR)” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu OAuth2 & OpenID Connect Deep Dive, przejdź na CoddyKit PRO. Kurs OAuth2 & OpenID Connect Deep Dive zawiera 4 lekcji w sumie.
Co nauczysz się w „Pushed Authorization Requests (PAR)”?
Dowiedz się, jak Pushed Authorization Requests (RFC 9126) przenoszą parametry autoryzacji do bezpiecznego wywołania kanałem tylnym, poprawiając integralność i poufność zaawansowanych wdrożeń OAuth2. Ćwiczysz OAuth2 & OpenID Connect Deep Dive z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć OAuth2 & OpenID Connect Deep Dive?
Nie wymagamy żadnego doświadczenia. OAuth2 & OpenID Connect Deep Dive w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Pushed Authorization Requests (PAR)”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji OAuth2 & OpenID Connect Deep Dive?
Tak. Każda lekcja OAuth2 & OpenID Connect Deep Dive zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- FAPI i API klasy finansowej
- DPoP (Demonstrating Proof-of-Possession)
- Continuous Access Evaluation Protocol (CAEP)
- Pushed Authorization Requests (PAR)