Perintah dan konteks
Anda mengelola authorization server OAuth 2.0. Permintaan otorisasi klien berisi scope bernilai tinggi, indikator sumber daya, dan konteks transaksi. Tim menginginkan server memverifikasi asal dan integritas permintaan, dan terkadang menyembunyikan parameter tersebut. Rancang JWT-Secured Authorization Request (JAR): format Request Object, penandatanganan dan enkripsi, transport, masa berlaku, rotasi kunci, dan penanganan kegagalan.
Pertanyaan ini cocok untuk peran identitas, pembayaran, dan backend. RFC 9101 menempatkan parameter otorisasi dalam JWT; JWS menyediakan integritas dan autentikasi sumber, sedangkan JWE dapat menyediakan kerahasiaan. Bedakan JAR dari PAR: JAR melindungi request object, sedangkan PAR mengirimkannya langsung ke authorization server dan mengembalikan sebuah referensi.
Hal yang diuji oleh pewawancara
- Pemisahan tanggung jawab antara authorization endpoint, klien, direktori kunci, dan token endpoint.
- Validasi issuer, audience, algoritma, time claim, dan parameter OAuth.
- Penanganan konflik parameter luar, replay, penyalahgunaan sumber daya kriptografi atau dekompresi, dan rotasi kunci.
- Batasan ancaman yang jelas untuk JAR, PAR, PKCE, state, dan nonce.
- Operasionalisasi melalui observabilitas, peluncuran, dan kontrol rollback.
Pertanyaan klarifikasi
- Apakah klien bersifat publik atau rahasia (confidential)? Apakah klien menandatangani Request Object, atau backend tepercaya yang menandatanganinya?
- Apakah kita hanya memerlukan integritas, atau peramban dan perantara juga tidak boleh membaca scope, sumber daya, dan bidang transaksi?
- Bisakah parameter luar menimpa claim JWT? Apa kebijakan untuk
requestdanrequest_uriper klien? - Apakah ini login OIDC, otorisasi pembayaran, atau OAuth biasa? Apakah nonce, autentikasi step-up, dan audit non-repudiation diperlukan?
- Apakah kunci didaftarkan secara statis, disajikan melalui JWKS, atau disimpan dalam HSM? Apa target rotasi dan pencabutannya?
Jawaban 30 detik
Pertama, tentukan siapa yang boleh menerbitkan Request Object serta kunci dan algoritma mana yang dipercaya. Validasi iss, aud, client_id, redirect_uri, response_type, scope, time claim, dan pengidentifikasi replay. Gunakan JWS yang masuk allow-list untuk integritas dan autentikasi sumber; tambahkan JWE saat permintaan harus bersifat rahasia. Perlakukan claim JWT yang dilindungi sebagai otoritatif dan tolak konflik luar. Batasi ukuran dan masa berlaku, lacak jti dengan TTL, dan terapkan fail-closed untuk permintaan berisiko tinggi saat verifikasi tidak tersedia. JAR melindungi objek, PAR melindungi transport dan masa berlaku referensi, dan PKCE mengikat pihak yang menukarkan kode otorisasi.
Jawaban mendalam
1. Menetapkan batas kepercayaan Request Object
Klien dapat mengirimkan JWT dalam request, atau mengirimkannya melalui PAR dan kemudian mereferensikannya dengan request_uri. Authorization server menggunakan registrasi klien untuk memilih penerbit dan algoritma tepercaya; server tidak boleh mengambil kunci sembarangan hanya karena header JWT berisi kid atau jku.
Claim seperti iss, aud, client_id, redirect_uri, response_type, scope, dan sumber daya harus cocok dengan registrasi dan konteks otorisasi. Nilai luar yang tidak ditandatangani tidak boleh mengubah nilai yang ditandatangani secara diam-diam; parameter kritis yang berkonflik atau duplikat akan ditolak.
2. Memilih JWS, JWE, dan kebijakan algoritma
Gunakan JWS jika integritas dan autentikasi sumber diperlukan. Gunakan JWE jika permintaan berisi bidang yang tidak boleh dibaca oleh peramban atau perantara. Terapkan allow-list algoritma, tolak none dan peralihan algoritma, serta batasi ukuran header, nesting, dan total bita.
Kunci penerima untuk JWE berasal dari registrasi authorization-server yang tepercaya. Kunci verifikasi JWS berasal dari registrasi klien atau direktori JWKS tepercaya. Kegagalan dekripsi, tanda tangan, dan claim berbagi satu batasan kesalahan bisnis agar respons tidak mengungkapkan detail keberadaan kunci atau permintaan.
3. Memvalidasi claim dan jendela waktu
Validasi iss, aud, exp, serta claim nbf dan iat yang berlaku. Buat exp tetap singkat; izinkan clock skew yang terbatas saja. Gunakan jti atau pengidentifikasi unik yang setara untuk audit dan deteksi replay, lalu tolak penggunaan kedua kali atau wajibkan pembuatan ulang.
Server tetap melakukan pencocokan redirect-URI secara persis dan memeriksa jenis respons serta scope yang diizinkan untuk klien. Tanda tangan JAR yang valid tidak berarti bahwa pengguna telah diautentikasi atau telah memberikan persetujuan (consent); keputusan sesi, persetujuan, tingkat jaminan, dan risiko tetap menjadi tanggung jawab authorization-endpoint.
4. Menyelesaikan parameter luar dan sumber permintaan
Urai sumber permintaan sebelum menerapkan prioritas parameter sesuai spesifikasi. Jika request dan parameter kueri biasa muncul bersamaan, nilai luar yang tidak ditandatangani tidak boleh menimpa claim JWT yang dilindungi. Ketidakcocokan, duplikasi, atau hilangnya claim kritis akan menghasilkan invalid_request.
Dengan PAR, klien mengirimkan Request Object langsung ke authorization server, yang kemudian mengembalikan request_uri berumur pendek. Peramban kemudian hanya membawa referensi tersebut, mengurangi kebocoran URL dan batas panjang URL. PAR tidak menggantikan penandatanganan atau enkripsi JAR, dan JAR sendiri tidak mengelola masa berlaku referensi.
5. Menahan replay, substitusi, dan penyalahgunaan sumber daya
Gunakan ID klien ditambah jti sebagai kunci deduplikasi di penyimpanan ber-TTL; alur berisiko tinggi dapat mewajibkan konsumsi sekali pakai. Batasi ukuran JWT, nesting, CPU dekripsi, dan frekuensi penyegaran JWKS untuk membatasi penyalahgunaan kriptografi dan kompresi.
Ikat Request Object ke klien dan redirect URI. Dikombinasikan dengan PKCE, state, dan nonce OIDC, ini mengatasi intersepsi kode otorisasi, CSRF sesi, dan substitusi respons autentikasi. Jangan pernah mencatat JWT lengkap, bidang transaksi, atau client assertion ke dalam log.
6. Merancang direktori kunci dan rotasi
Beri setiap kunci verifikasi klien dan setiap kunci enkripsi authorization-server sebuah versi, tujuan, dan status. Cache JWKS memerlukan TTL yang eksplisit. Selama rotasi, publikasikan kunci baru, alihkan penerbit, pertahankan kunci lama selama masa berlaku permintaan atau token terlama, lalu cabut kunci tersebut.
Jika kid tidak ditemukan, izinkan satu kali penyegaran direktori yang terkontrol daripada percobaan ulang eksternal tanpa batas. Pencabutan kunci, pemadaman direktori, dan ketidakcocokan algoritma memerlukan metrik dan peringatan; klien berisiko tinggi menerapkan fail-closed jika verifikasi tidak dapat diselesaikan.
7. Menambahkan observabilitas, peluncuran, dan rollback
Catat hash request-object, klien, algoritma, hasil verifikasi, jti yang di-hash, dan latensi, jangan pernah mencatat ciphertext atau token lengkap. Lacak kegagalan tanda tangan dan dekripsi, konflik claim, kedaluwarsa, duplikasi jti, penyegaran JWKS, dan penyelesaian otorisasi.
Aktifkan JAR per klien, bandingkan tingkat penyelesaian, latensi, dan distribusi kesalahan dengan alur lama, serta jeda peluncuran jika sinyal direktori kunci atau kompatibilitas mengalami regresi. Rollback harus memulihkan kebijakan yang disetujui secara eksplisit; rollback tidak boleh mengubah parameter luar yang tidak ditandatangani menjadi fallback untuk scope berisiko tinggi.
Jawaban model
Saya akan memperlakukan JAR sebagai lapisan integritas dan kerahasiaan untuk permintaan otorisasi. Klien atau backend tepercaya membuat Request Object sesuai dengan registrasi. Authorization server hanya menerima algoritma yang ada di allow-list dan kunci tepercaya, memvalidasi issuer, audience, klien, redirect URI, jenis respons, scope, iat/exp, dan jti, serta menolak nilai luar yang tidak ditandatangani yang berkonflik dengan claim yang dilindungi. Gunakan JWS untuk integritas dan autentikasi sumber, serta JWE untuk kerahasiaan.
Beri objek masa berlaku yang pendek dan pengikatan klien, lakukan deduplikasi jti dengan TTL, dan batasi ukuran, nesting, serta sumber daya dekripsi. Gunakan kunci JWKS berversi dengan masa tumpang tindih selama rotasi. JAR dapat dipadukan dengan PAR: JAR melindungi objek, PAR menyembunyikan parameter peramban dan mengelola referensi, sementara PKCE, state, dan nonce mempertahankan pengikatan kode dan sesi masing-masing secara terpisah.
Luncurkan per klien sambil mengamati kegagalan verifikasi, replay, penyegaran JWKS, tingkat penyelesaian, dan latensi. Kegagalan direktori kunci atau permintaan berisiko tinggi yang tidak dapat diverifikasi akan menerapkan fail-closed. Rollback memulihkan kebijakan lama yang telah ditentukan dan tidak pernah memperlakukan parameter luar yang tidak ditandatangani sebagai perlindungan yang setara.
Kesalahan umum
- Mengatakan "tanda tangan JWT itu aman" tanpa memeriksa issuer, audience, algoritma, waktu, dan redirect URI.
- Membiarkan
kidataujkumemicu pengambilan kunci jaringan secara sembarangan, memperluas cakupan kepercayaan dan risiko SSRF. - Mengizinkan nilai kueri luar menimpa scope atau redirect URI yang telah ditandatangani.
- Memperlakukan JAR, PAR, dan PKCE sebagai satu fitur tunggal, bukannya sebagai perlindungan permintaan, transport, dan kode yang terpisah.
- Menghilangkan
jti, TTL pendek, batas ukuran, atau batas sumber daya kriptografi. - Menghapus kunci lama secara langsung selama rotasi sehingga merusak permintaan yang sebenarnya masih valid.
- Melakukan fallback tanpa syarat ke otorisasi biasa setelah verifikasi gagal.
Pertanyaan lanjutan dan jawaban
Apa perbedaan tanda tangan klien dan authorization-server?
Tanda tangan klien memungkinkan server mengautentikasi sumber permintaan dan mendeteksi manipulasi. Tanda tangan server biasanya membawa atestasi server ke arah downstream. Trust anchor, tujuan kunci, dan pemilik rotasi keduanya berbeda.
Mengapa PKCE tetap diperlukan saat JAR sudah ditandatangani?
JAR melindungi konten permintaan; PKCE melindungi pihak yang menukarkan kode otorisasi. Callback peramban yang dicegat tetap memerlukan verifier.
Haruskah setiap parameter berada di dalam JWT?
Tempatkan parameter yang memerlukan integritas, autentikasi sumber, atau kerahasiaan di dalam Request Object. Tentukan urutan prioritas untuk parameter luar yang diizinkan dan tolak konflik atau nilai kritis yang hilang.
Bagaimana jika JWKS tidak tersedia untuk sementara?
Gunakan cache berumur pendek dan satu kali penyegaran terkontrol. Jika tidak ada kunci tepercaya yang tersedia, terapkan fail-closed untuk permintaan berisiko tinggi dan kirimkan peringatan. Jangan pernah menerima kunci yang tidak dikenal atau melewatkan verifikasi demi ketersediaan.
Bagaimana cara memigrasikan klien yang hanya mendukung permintaan biasa?
Aktifkan JAR melalui metadata klien, ukur verifikasi dan penyelesaian, lalu wajibkan untuk klien yang sudah dimigrasikan. Konfigurasikan scope yang tersisa, batas risiko, dan tanggal penghentian (sunset date) secara eksplisit untuk alur lama.
Bagaimana Anda membuktikan bahwa JWT sensitif tidak ada dalam log?
Terapkan penyuntingan (redaction) bidang pada gateway, layanan otorisasi, dan pelacak kesalahan. Simpan hanya hash objek dan hash jti, klien, serta hasilnya; lakukan sampling log dan jalankan pemeriksaan regresi yang menolak token, ciphertext, dan bidang transaksi.