Wawancara Backend: Bagaimana Anda Mengamankan OAuth 2.0 Pushed Authorization Requests?

Pertanyaan dan konteks yang berlaku

Anda mengelola server otorisasi OAuth 2.0. Klien web seluler dan enterprise membawa scope terperinci, indikator sumber daya, dan konteks pembayaran, tetapi tim tidak ingin permintaan lengkap tersebut terlihat di URL browser. Rancang endpoint Pushed Authorization Request (PAR). Cakup autentikasi klien, pembuatan dan pengikatan request_uri, kedaluwarsa, penggunaan sekali pakai, replay, validasi redirect-URI, PKCE, error, rate limit, dan rollback.

Ini cocok untuk wawancara backend, platform identitas, dan sistem pembayaran. RFC 9126 mendefinisikan PAR sebagai push langsung dari klien ke server otorisasi yang mengembalikan request_uri untuk permintaan otorisasi browser berikutnya. Jawaban yang kuat juga menyatakan bahwa PAR tidak menghilangkan kebutuhan server otorisasi untuk memvalidasi permintaan selanjutnya tersebut.

Hal yang dinilai oleh pewawancara

• Menentukan batasan antara klien, endpoint PAR, endpoint otorisasi browser, dan token endpoint.
• Memisahkan autentikasi klien, autentikasi pengguna, integritas permintaan, dan pengikatan token.
• Menangani penebakan request_uri, penukaran (swapping), replay, kedaluwarsa, dan serangan redirect-URI.
• Menempatkan PKCE, state, nonce, JAR, dan PAR pada lapisan yang benar.
• Mengoperasionalkan TTL, idempoten, rate limit, audit, dan peluncuran canary.

RFC 9700 merangkum praktik terbaik keamanan OAuth 2.0 saat ini. Materi persiapan SDE II Amazon menekankan keandalan, akurasi, efisiensi, skalabilitas, dan keamanan dalam perancangan sistem. Sinyal wawancara yang dicari adalah mengubah standar-standar tersebut menjadi batasan layanan yang berjalan secara nyata.

Pertanyaan klarifikasi

1. Apakah klien bersifat rahasia (confidential) atau publik? Bisakah klien seluler melindungi rahasia klien (client secret), atau harus menggunakan PKCE dan pengikatan platform?
2. Data sensitif apa yang ada dalam permintaan? Apakah JAR yang ditandatangani atau dienkripsi diperlukan, dan bidang mana yang harus diperiksa pada saat PAR?
3. Berapa masa berlaku request_uri, toleransi refresh, konkurensi per klien, dan target rate limit global?
4. Apakah redirect URI bersifat tetap dan telah didaftarkan sebelumnya, atau apakah tenant enterprise memerlukan pendaftaran dinamis?
5. Haruskah setiap klien mengirimkan parameter otorisasi melalui PAR? Bagaimana klien lama akan dimigrasikan?
6. Apakah refresh browser, navigasi kembali, pembatalan, dan percobaan ulang jaringan boleh membaca permintaan yang sama lagi?

Kerangka jawaban 30 detik

Klien mengirimkan HTTPS POST ke PAR, melakukan autentikasi, dan memvalidasi parameter redirect URI, scope, sumber daya, dan PKCE. Server membuat request_uri berentropi tinggi, berumur pendek, dan terikat pada klien, lalu mengembalikan JSON. Browser kemudian hanya mengirimkan client_id dan request_uri ke endpoint otorisasi. Endpoint tersebut tetap memvalidasi ulang permintaan, state/nonce, persetujuan pengguna, dan PKCE sebelum mengonsumsi referensi tersebut. Rate limit, audit, kebijakan sekali pakai, flag kompatibilitas, dan metrik canary mengontrol peluncuran.

Jawaban mendalam langkah demi langkah

1. Tentukan protokol dua langkah (two-hop)

Langkah pertama adalah HTTPS POST langsung dari klien ke PAR dengan body application/x-www-form-urlencoded. Ini adalah tempat untuk mengautentikasi klien dan memvalidasi client_id, tipe respons, redirect URI, scope, indikator sumber daya, state, nonce, dan PKCE. RFC 9126 mewajibkan HTTPS untuk PAR dan mengizinkan ekstensi endpoint otorisasi.

Langkah kedua adalah permintaan agen pengguna (user agent) ke endpoint otorisasi, yang biasanya hanya membawa client_id dan request_uri. Server otorisasi mengambil permintaan yang disimpan pada langkah pertama alih-alih mempercayai parameter sensitif yang dikirim ulang oleh browser. Ini mengurangi kebocoran query string, batasan ukuran URL, dan manipulasi agen pengguna.

2. Rancang penyimpanan request_uri

Buat request_uri dengan nilai acak yang aman secara kriptografis, jangan pernah menggunakan ID yang bertambah bertahap (incrementing ID) atau kunci bisnis yang dapat ditebak. Simpan permintaan lengkap, ID klien, waktu pembuatan, kedaluwarsa, status konsumsi, dan bidang audit yang di-hash; ikat referensi ke klien yang membuatnya.

Pertahankan TTL tetap singkat dan kembalikan sebagai expires_in. Referensi yang kedaluwarsa mengembalikan invalid_request; referensi yang tidak dikenal tidak boleh mengungkapkan apakah referensi tersebut pernah ada. Konsumsi sekali pakai adalah yang paling aman. Jika produk harus mendukung refresh, izinkan jendela waktu singkat dengan batas jumlah pembacaan, pengikatan state/nonce, dan batasan ketat.

3. Validasi klien dan permintaan

Autentikasi klien di PAR menggunakan aturan token-endpoint, seperti mTLS atau private_key_jwt. Autentikasi membuktikan klien mana yang mengirimkan permintaan; itu tidak membuktikan bahwa pengguna telah masuk atau menyetujui suatu scope. Validasi redirect URI yang terdaftar, scope yang diizinkan, sumber daya, dan tipe respons di PAR, kemudian ulangi pemeriksaan yang memerlukan konteks pengguna pada saat otorisasi.

Jika klien menggunakan Request Object yang ditandatangani, validasi tanda tangan, penerbit (issuer), audiens, kedaluwarsa, dan bidang kritisnya berdasarkan aturan JAR. PAR adalah push langsung dan siklus hidup referensi; JAR adalah penandatanganan atau enkripsi Request Object. Keduanya dapat digabungkan, tetapi tidak saling menggantikan.

4. Tempatkan PKCE, state, dan nonce pada lapisan yang tepat

PAR tetap membawa code_challenge dan metodenya; token endpoint harus memverifikasi code_verifier saat menukarkan kode. state mengikat sesi klien dan memitigasi CSRF. nonce OIDC mengikat permintaan autentikasi ke ID token. Keberadaan request_uri bukan alasan untuk menghapus kontrol ini atau memperlakukannya sebagai sesuatu yang dapat dipertukarkan.

5. Cegah penukaran (swapping), replay, dan open redirect

Jika penyerang mengganti permintaan dengan permintaan lain yang mereka peroleh, scope atau tingkat jaminan dapat berubah. Ikat referensi ke klien dan wajibkan konteks klien pada permintaan otorisasi cocok. Klien menggunakan state dan PKCE yang unik; OIDC menggunakan nonce. Cocokkan redirect URI secara ketat sehingga PAR tidak dapat menjadi titik masuk open-redirect.

Kembalikan error yang eksplisit tetapi tidak memungkinkan enumerasi ketika referensi yang telah dikonsumsi digunakan kembali. Catat klien, hash referensi, waktu, sinyal risiko, dan hasil untuk mendeteksi penebakan dan replay. Jauhkan permintaan otorisasi lengkap, asersi klien, dan parameter sumber daya sensitif dari log akses biasa.

6. Rancang penanganan error, batas, dan ketersediaan

Parameter yang tidak valid, redirect URI yang tidak cocok, atau tanda tangan yang buruk menggunakan error OAuth seperti invalid_request. Metode yang salah dapat menghasilkan 405, permintaan yang terlalu besar 413, dan pelanggaran kuota 429. Terapkan batasan berdasarkan klien, tenant, IP, dan penyimpanan global sehingga penyerang tidak dapat menghabiskan penyimpanan PAR.

Ketika PAR tidak tersedia, apakah klien yang dimigrasikan boleh beralih kembali (fallback) ke permintaan otorisasi reguler adalah keputusan kebijakan keamanan. Untuk pembayaran atau scope berisiko tinggi, gagalkan secara eksplisit alih-alih melemahkan alur secara diam-diam. Migrasikan klien lama melalui metadata, lalu secara bertahap terapkan require_pushed_authorization_requests.

7. Operasikan masa pakai data dan observabilitas

Pertahankan data referensi hanya selama TTL, konsumsi, dan periode audit yang diperlukan. Gunakan penyimpanan terenkripsi, kontrol akses, dan minimalisasi data; jangan menyalin konteks otorisasi sensitif ke banyak cache. Lacak keberhasilan PAR, kegagalan validasi, kedaluwarsa, konsumsi duplikat, tingkat 429, tingkat kehilangan referensi saat otorisasi, dan kegagalan PKCE saat penukaran token.

Lakukan canary alur reguler dan alur PAR secara berdampingan. Bandingkan tingkat penyelesaian, latensi halaman pertama, fallback seluler, dan peringatan keamanan. Pengujian otomatis harus mencakup konsumsi bersamaan, penukaran referensi, varian redirect-URI, refresh browser, permintaan berukuran besar, dan kompatibilitas klien lama.

Contoh jawaban berkualitas tinggi

Saya akan membagi alur menjadi dua langkah. Klien memanggil PAR melalui HTTPS, melakukan autentikasi, dan memvalidasi redirect URI, scope, sumber daya, tipe respons, PKCE, state, dan nonce. Server membuat request_uri berentropi tinggi, berumur pendek, dan terikat pada klien, lalu hanya mengembalikan referensi dan expires_in. Browser kemudian memanggil endpoint otorisasi dengan ID klien dan referensi tersebut; server mengambil permintaan asli dan melakukan pemeriksaan otorisasi, sesi pengguna, state/nonce, dan PKCE sekali lagi.

Referensi menyimpan permintaan, pengikatan klien, kedaluwarsa, dan status konsumsi, dengan aturan sekali pakai secara default. Fitur refresh menggunakan jendela waktu singkat, batas pembacaan, dan audit. JAR menangani penandatanganan atau enkripsi Request Object; PAR menangani push langsung dan masa pakai referensi. Pencocokan redirect-URI yang ketat mencegah penukaran dan open redirect, sementara error OAuth serta batasan per klien, IP, dan tenant membuat penyalahgunaan terlihat jelas.

Saya akan melakukan canary berdasarkan metadata klien sambil mempertahankan alur lama, mengukur tingkat penyelesaian, latensi, kedaluwarsa, penggunaan duplikat, error 429, dan kegagalan PKCE. Klien berisiko tinggi tidak melakukan fallback diam-diam. Gangguan penyimpanan atau lonjakan replay akan menghentikan peluncuran dan membatalkan flag penegakan wajib. Hal ini mengurangi kebocoran URL dan manipulasi parameter tanpa mengubah batasan persetujuan pengguna dan penukaran kode OAuth.

Kesalahan umum

• Hanya mengatakan "masukkan parameter ke dalam POST" tanpa autentikasi klien, pengikatan referensi, atau kedaluwarsa.
• Memperlakukan request_uri sebagai access token atau menjadikannya ID database yang dapat ditebak.
• Menganggap PAR secara otomatis mencegah replay dan mengabaikan sekali pakai, TTL, state, nonce, atau PKCE.
• Mencampuradukkan PAR, JAR, dan PKCE tanpa menjelaskan batasan perlindungan masing-masing.
• Memvalidasi redirect URI hanya di PAR dan mempercayai parameter browser pada saat otorisasi.
• Mengabaikan 413, 429, konsumsi bersamaan, kebocoran cache, dan pencatatan data sensitif pada log.
• Melakukan fallback tanpa syarat ke otorisasi reguler saat PAR gagal, yang memperluas paparan scope berisiko tinggi.

Pertanyaan lanjutan dan jawaban

Berapa lama request_uri harus aktif?

Gunakan TTL pendek berdasarkan risiko dan kembalikan expires_in. Hapus atau batalkan setelah kedaluwarsa atau dikonsumsi; simpan hanya bidang hash, klien, dan hasil minimal untuk audit.

Bisakah refresh browser menggunakan kembali referensi tersebut?

Tetapkan default ke penggunaan sekali pakai. Jika refresh diperlukan, gunakan jendela waktu singkat, batas pembacaan, dan pengikatan state, nonce, serta sesi klien sambil memantau pembacaan duplikat. Jangan izinkan penggunaan kembali tanpa batas.

Mengapa PKCE masih diperlukan setelah autentikasi klien?

Autentikasi klien mengidentifikasi klien mana yang mengirimkan permintaan. PKCE mengikat penukaran kode ke pemohon yang memegang verifier. Ini tetap penting bagi klien publik dan seluler jika kode otorisasi dicegat.

Bisakah PAR menggantikan JAR?

Tidak. PAR menangani push langsung, penyembunyian parameter browser, dan masa pakai referensi. JAR menangani penandatanganan atau enkripsi Request Object. Gabungkan keduanya jika diperlukan integritas yang lebih kuat atau non-repudiation.

Bagaimana klien lama harus dimigrasikan?

Aktifkan PAR melalui metadata server otorisasi dan kebijakan klien, pantau dukungannya, lalu wajibkan require_pushed_authorization_requests untuk klien tertentu. Pertahankan jalur lama yang dibatasi dan diaudit alih-alih mengalihkan seluruh ekosistem secara membabi buta.

Bagaimana jika endpoint PAR menerima lonjakan lalu lintas yang masif (flood)?

Batasi berdasarkan klien, tenant, IP, dan sumber daya global; batasi ukuran body dan TTL penyimpanan; kembalikan 429; serta pantau tingkat kegagalan dan watermark penyimpanan. Klien berisiko tinggi tidak boleh diturunkan keamanannya secara diam-diam karena tekanan lalu lintas.