Permintaan Otorisasi yang Didorong (PAR)
Pelajari cara Permintaan Otorisasi yang Didorong (RFC 9126) memindahkan parameter otorisasi ke panggilan saluran balik yang aman, sehingga meningkatkan integritas dan kerahasiaan dalam penerapan OAuth2 tingkat lanjut.
Permintaan Otorisasi yang Didorong (PAR) adalah pelajaran OAuth2 & OpenID Connect Deep Dive gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar OAuth2 & OpenID Connect Deep Dive, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus OAuth2 & OpenID Connect Deep Dive mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
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.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Permintaan Otorisasi yang Didorong (PAR)” gratis?
Ya — teks lengkap “Permintaan Otorisasi yang Didorong (PAR)” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus OAuth2 & OpenID Connect Deep Dive, upgrade ke CoddyKit PRO. Kursus OAuth2 & OpenID Connect Deep Dive mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Permintaan Otorisasi yang Didorong (PAR)”?
Pelajari cara Permintaan Otorisasi yang Didorong (RFC 9126) memindahkan parameter otorisasi ke panggilan saluran balik yang aman, sehingga meningkatkan integritas dan kerahasiaan dalam penerapan OAut… Kamu berlatih OAuth2 & OpenID Connect Deep Dive dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai OAuth2 & OpenID Connect Deep Dive?
Tidak diperlukan pengalaman sebelumnya. OAuth2 & OpenID Connect Deep Dive di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Permintaan Otorisasi yang Didorong (PAR)” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran OAuth2 & OpenID Connect Deep Dive ini?
Ya. Setiap pelajaran OAuth2 & OpenID Connect Deep Dive menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- FAPI dan API Tingkat Finansial
- DPoP (Demonstrating Proof-of-Possession)
- Continuous Access Evaluation Protocol (CAEP)
- Permintaan Otorisasi yang Didorong (PAR)