Gesaan dan konteks
Anda memiliki pelayan kebenaran (authorization server) OAuth 2.0. Permintaan kebenaran klien mengandungi skop bernilai tinggi, penunjuk sumber, dan konteks transaksi. Pasukan mahu pelayan mengesahkan punca dan integriti permintaan, serta kadangkala menyembunyikan parameter tersebut. Reka bentuk JWT-Secured Authorization Request (JAR): format Request Object, penandatanganan dan penyulitan, pengangkutan, jangka hayat, penggiliran kunci, dan pengendalian kegagalan.
Soalan ini sesuai untuk peranan identiti, pembayaran, dan backend. RFC 9101 meletakkan parameter kebenaran dalam JWT; JWS menyediakan integriti dan pengesahan sumber, manakala JWE boleh menyediakan kerahsiaan. Bezakan JAR daripada PAR: JAR melindungi request object, manakala PAR menolaknya secara langsung ke authorization server dan mengembalikan rujukan.
Perkara yang diuji oleh penemu duga
- Pemisahan tanggungjawab antara authorization endpoint, klien, direktori kunci, dan token endpoint.
- Pengesahan issuer, audience, algoritma, tuntutan masa (time claims), dan parameter OAuth.
- Pengendalian konflik parameter luar, replay, penyalahgunaan sumber penyahmampatan atau kripto, dan penggiliran kunci.
- Sempadan ancaman yang jelas untuk JAR, PAR, PKCE, state, dan nonce.
- Pengoperasian melalui kebolehcerapan (observability), pelancaran, dan kawalan pengunduran (rollback).
Soalan penjelasan
- Adakah klien bersifat awam atau sulit (confidential)? Adakah klien menandatangani Request Object, atau backend yang dipercayai yang menandatanganinya?
- Adakah kita memerlukan integriti sahaja, atau adakah penyemak imbas dan perantara tidak boleh membaca skop, sumber, dan medan transaksi?
- Bolehkah parameter luar mengatasi tuntutan JWT? Apakah dasar untuk
requestdanrequest_uribagi setiap klien? - Adakah ini log masuk OIDC, kebenaran pembayaran, atau OAuth biasa? Adakah nonce, pengesahan step-up, dan audit tanpa penafian (non-repudiable) diperlukan?
- Adakah kunci didaftarkan secara statik, disediakan melalui JWKS, atau disimpan dalam HSM? Apakah sasaran penggiliran dan pembatalan?
Jawapan 30 saat
Mula-mula tetapkan pihak yang boleh mengeluarkan Request Object serta kunci dan algoritma yang dipercayai. Sahkan iss, aud, client_id, redirect_uri, response_type, skop, tuntutan masa, dan pengenal pasti replay. Gunakan JWS yang tersenarai dalam senarai dibenarkan (allow-list) untuk integriti dan pengesahan sumber; tambah JWE apabila permintaan mesti dirahsiakan. Layan tuntutan JWT yang dilindungi sebagai berwibawa dan tolak konflik luar. Hadkan saiz dan jangka hayat, jejak jti dengan TTL, dan laksanakan fail-closed untuk permintaan berisiko tinggi apabila pengesahan tidak tersedia. JAR melindungi objek, PAR melindungi pengangkutan dan jangka hayat rujukan, dan PKCE mengikat penebus kod kebenaran.
Jawapan mendalam
1. Menetapkan sempadan kepercayaan Request Object
Klien boleh menghantar JWT dalam request, atau menyerahkannya melalui PAR dan kemudian merujuknya dengan request_uri. Pelayan kebenaran menggunakan pendaftaran klien untuk memilih pengeluar dan algoritma yang dipercayai; ia tidak boleh mengambil kunci sewenang-wenangnya hanya kerana pengepala JWT mengandungi kid atau jku.
Tuntutan seperti iss, aud, client_id, redirect_uri, response_type, skop, dan sumber mesti sepadan dengan pendaftaran dan konteks kebenaran. Nilai luar yang tidak ditandatangani tidak boleh mengubah nilai yang ditandatangani secara senyap; parameter kritikal yang berkonflik atau bertindih akan ditolak.
2. Memilih JWS, JWE, dan dasar algoritma
Gunakan JWS apabila integriti dan pengesahan sumber diperlukan. Gunakan JWE apabila permintaan mengandungi medan yang tidak boleh dibaca oleh penyemak imbas atau perantara. Kuat kuasakan senarai dibenarkan untuk algoritma, tolak none dan pertukaran algoritma, serta hadkan saiz pengepala, penumpukan (nesting), dan jumlah bait.
Kunci penerima untuk JWE datang daripada pendaftaran authorization-server yang dipercayai. Kunci pengesahan JWS datang daripada pendaftaran klien atau direktori JWKS yang dipercayai. Kegagalan penyahsulitan, tandatangan, dan tuntutan berkongsi satu sempadan ralat perniagaan supaya respons tidak mendedahkan butiran kewujudan kunci atau permintaan.
3. Mengesahkan tuntutan dan tetingkap masa
Sahkan iss, aud, exp, serta tuntutan nbf dan iat yang berkenaan. Pastikan exp pendek; benarkan sisihan jam (clock skew) yang terhad sahaja. Gunakan jti atau pengenal pasti unik yang setara untuk audit dan pengesanan replay, dan tolak penggunaan kali kedua atau wajibkan penjanaan semula.
Pelayan masih melakukan pemadanan redirect-URI yang tepat dan menyemak jenis respons serta skop yang dibenarkan untuk klien. Tandatangan JAR yang sah tidak bermakna pengguna telah disahkan atau telah memberikan persetujuan; keputusan sesi, persetujuan, tahap jaminan, dan risiko kekal sebagai tanggungjawab authorization-endpoint.
4. Menyelesaikan parameter luar dan sumber permintaan
Huraikan (parse) sumber permintaan sebelum menggunakan keutamaan parameter mengikut spesifikasi. Jika request dan parameter pertanyaan biasa muncul bersama, nilai luar yang tidak ditandatangani tidak boleh mengatasi tuntutan JWT yang dilindungi. Ketidakpadanan, penduaan, atau ketiadaan tuntutan kritikal akan mengembalikan invalid_request.
Dengan PAR, klien menghantar Request Object terus ke authorization server, yang kemudiannya mengembalikan request_uri jangka pendek. Penyemak imbas kemudian hanya membawa rujukan tersebut, mengurangkan kebocoran URL dan had panjang URL. PAR tidak menggantikan penandatanganan atau penyulitan JAR, dan JAR sendiri tidak menguruskan jangka hayat rujukan.
5. Menentang replay, penggantian, dan penyalahgunaan sumber
Gunakan ID klien bersama jti sebagai kunci penyahduplikasian dalam stor TTL; aliran berisiko tinggi boleh memerlukan penggunaan sekali sahaja. Hadkan saiz JWT, nesting, CPU penyahsulitan, dan kekerapan penyegaran JWKS untuk mengehadkan penyalahgunaan kripto dan pemampatan.
Ikat Request Object kepada klien dan redirect URI. Digabungkan dengan PKCE, state, dan nonce OIDC, ini menangani pemintasan kod kebenaran, CSRF sesi, dan penggantian respons pengesahan. Jangan sekali-kali merekodkan JWT lengkap, medan transaksi, atau client assertion dalam log.
6. Mereka bentuk direktori kunci dan penggiliran
Berikan setiap kunci pengesahan klien dan setiap kunci penyulitan authorization-server versi, tujuan, dan status. Cache JWKS memerlukan TTL yang jelas. Semasa penggiliran, terbitkan kunci baharu, tukar pengeluar, kekalkan kunci lama sepanjang jangka hayat permintaan atau token yang paling lama, kemudian batalkannya.
Jika kid hilang, benarkan satu penyegaran direktori yang terkawal dan bukannya percubaan semula luaran tanpa had. Pembatalan kunci, gangguan direktori, dan ketidakpadanan algoritma memerlukan metrik dan amaran; klien berisiko tinggi akan fail-closed apabila pengesahan tidak dapat diselesaikan.
7. Menambah kebolehcerapan, pelancaran, dan pengunduran
Catatkan cincangan (hash) request-object, klien, algoritma, keputusan pengesahan, jti yang dicincang, dan kependaman (latency), jangan sekali-kali teks sifer atau token lengkap. Jejak kegagalan tandatangan dan penyahsulitan, konflik tuntutan, tamat tempoh, penduaan jti, penyegaran JWKS, dan penyiapan kebenaran.
Dayakan JAR mengikut klien, bandingkan kadar penyiapan, kependaman, dan taburan ralat dengan aliran lama, dan jedakan pelancaran apabila isyarat direktori kunci atau keserasian merosot. Rollback harus memulihkan dasar yang diluluskan secara eksplisit; ia tidak sepatutnya menjadikan parameter luar yang tidak ditandatangani sebagai sandaran (fallback) untuk skop berisiko tinggi.
Jawapan model
Saya akan menganggap JAR sebagai lapisan integriti dan kerahsiaan bagi permintaan kebenaran. Klien atau backend yang dipercayai mencipta Request Object mengikut pendaftaran. Pelayan kebenaran hanya menerima algoritma yang tersenarai dalam senarai dibenarkan dan kunci yang dipercayai, mengesahkan issuer, audience, klien, redirect URI, jenis respons, skop, iat/exp, dan jti, serta menolak nilai luar yang tidak ditandatangani yang berkonflik dengan tuntutan yang dilindungi. Gunakan JWS untuk integriti dan pengesahan sumber, dan JWE untuk kerahsiaan.
Berikan objek jangka hayat yang pendek dan pengikatan klien, nyahduplikasi jti dengan TTL, dan hadkan saiz, nesting, serta sumber penyahsulitan. Gunakan kunci JWKS berversi dengan tempoh pertindihan semasa penggiliran. JAR boleh digabungkan dengan PAR: JAR melindungi objek, PAR menyembunyikan parameter penyemak imbas dan mengurus rujukan, manakala PKCE, state, dan nonce mengekalkan pengikatan kod dan sesi mereka yang berasingan.
Lancarkan mengikut klien sambil memerhatikan kegagalan pengesahan, replay, penyegaran JWKS, kadar penyiapan, dan kependaman. Kegagalan direktori kunci atau permintaan berisiko tinggi yang tidak dapat disahkan akan fail-closed. Rollback memulihkan dasar lama yang telah ditetapkan dan tidak sekali-kali menganggap parameter luar yang tidak ditandatangani sebagai perlindungan yang setara.
Kesilapan lazim
- Mengatakan "tandatangan JWT adalah selamat" tanpa menyemak issuer, audience, algoritma, masa, dan redirect URI.
- Membenarkan
kidataujkumencetuskan pengambilan kunci rangkaian secara sewenang-wenangnya, meluaskan kepercayaan dan risiko SSRF. - Membenarkan nilai pertanyaan luar mengatasi skop yang ditandatangani atau redirect URI.
- Menganggap JAR, PAR, dan PKCE sebagai satu ciri tunggal dan bukannya perlindungan permintaan, pengangkutan, dan kod yang berbeza.
- Meninggalkan
jti, TTL pendek, had saiz, atau had sumber kripto. - Memadamkan kunci lama serta-merta semasa penggiliran dan merosakkan permintaan yang masih sah.
- Kembali kepada kebenaran biasa tanpa syarat selepas pengesahan gagal.
Soalan susulan dan jawapan
Bagaimanakah tandatangan klien dan authorization-server berbeza?
Tandatangan klien membolehkan pelayan mengesahkan punca permintaan dan mengesan pengubahan. Tandatangan pelayan biasanya membawa perakuan pelayan ke peringkat hiliran. Trust anchor, tujuan kunci, dan pemilik penggiliran bagi kedua-duanya adalah berbeza.
Mengapakah PKCE masih diperlukan apabila JAR telah ditandatangani?
JAR melindungi kandungan permintaan; PKCE melindungi pihak yang menebus kod kebenaran. Panggilan balik penyemak imbas yang dipintas masih memerlukan verifier.
Adakah setiap parameter mesti berada di dalam JWT?
Letakkan parameter yang memerlukan integriti, pengesahan sumber, atau kerahsiaan di dalam Request Object. Tentukan keutamaan untuk parameter luar yang dibenarkan dan tolak konflik atau ketiadaan nilai kritikal.
Bagaimana jika JWKS tidak tersedia buat sementara waktu?
Gunakan cache jangka pendek dan satu penyegaran terkawal. Jika tiada kunci yang dipercayai tersedia, laksanakan fail-closed untuk permintaan berisiko tinggi dan keluarkan amaran. Jangan sekali-kali menerima kunci yang tidak diketahui atau melangkau pengesahan demi ketersediaan.
Bagaimanakah anda memindahkan klien yang hanya menyokong permintaan biasa?
Dayakan JAR melalui metadata klien, ukur pengesahan dan penyiapan, kemudian wajibkannya untuk klien yang telah dipindahkan. Konfigurasikan skop yang selebihnya, had risiko, dan tarikh penamatan (sunset date) secara eksplisit untuk aliran lama.
Bagaimanakah anda membuktikan bahawa JWT sensitif tiada dalam log?
Gunakan pemadanan/penyuntingan (redaction) medan pada get laluan (gateway), perkhidmatan kebenaran, dan penjejak ralat. Kekalkan hanya cincangan objek dan jti, klien, serta hasil; lakukan pensampelan log dan jalankan semakan regresi yang menolak token, teks sifer, dan medan transaksi.