Temu Duga Backend: Bagaimana Anda Akan Menjamin Keselamatan OAuth 2.0 Pushed Authorization Requests?

Gesaan dan konteks berkaitan

Anda memiliki sebuah pelayan kebenaran OAuth 2.0. Klien web mudah alih dan perusahaan membawa skop terperinci, penunjuk sumber, dan konteks pembayaran, tetapi pasukan tidak mahu permintaan penuh berada dalam URL penyemak imbas. Reka bentuk titik akhir Pushed Authorization Request (PAR). Rangkap pengesahan klien, penjanaan dan pengikatan request_uri, tamat tempoh, penggunaan sekali sahaja, ulangan, pengesahan redirect-URI, PKCE, ralat, had kadar, dan pengunduran.

Ini sesuai untuk temu duga backend, platform identiti, dan pembayaran. RFC 9126 mentakrifkan PAR sebagai tolakan langsung daripada klien ke pelayan kebenaran yang mengembalikan request_uri untuk permintaan kebenaran penyemak imbas kemudiannya. Jawapan yang mantap juga menyatakan bahawa PAR tidak menghapuskan keperluan pelayan kebenaran untuk mengesahkan permintaan seterusnya.

Perkara yang dinilai oleh penemu duga

• Menetapkan sempadan antara klien, titik akhir PAR, titik akhir kebenaran penyemak imbas, dan titik akhir token.
• Mengasingkan pengesahan klien, pengesahan pengguna, integriti permintaan, dan pengikatan token.
• Mengendalikan tekaan request_uri, pertukaran (swapping), ulangan, tamat tempoh, dan serangan redirect-URI.
• Meletakkan PKCE, state, nonce, JAR, dan PAR pada lapisan yang betul.
• Menjadikan TTL, keidempoteman (idempotency), had kadar, audit, dan pelancaran kanari (canary rollout) beroperasi dengan baik.

RFC 9700 meringkaskan amalan terbaik keselamatan OAuth 2.0 semasa. Bahan persediaan SDE II Amazon menekankan kebolehpercayaan, ketepatan, kecekapan, kebolehskalaan, dan keselamatan dalam reka bentuk sistem. Isyarat temu duga adalah menukar piawaian tersebut kepada sempadan perkhidmatan yang sedang berjalan.

Soalan penjelasan

1. Adakah klien bersifat sulit (confidential) atau awam (public)? Bolehkah klien mudah alih melindungi rahsia klien (client secret), atau adakah ia mesti menggunakan PKCE dan pengikatan platform?
2. Apakah data sensitif yang terdapat dalam permintaan? Adakah JAR yang ditandatangani atau disulitkan diperlukan, dan medan manakah yang mesti diperiksa semasa PAR?
3. Apakah jangka hayat request_uri, elaun penyegaran (refresh allowance), keserentakan bagi setiap klien, dan sasaran had kadar global?
4. Adakah URI pengalihan ditetapkan dan dipra-daftar, atau adakah penyewa perusahaan memerlukan pendaftaran dinamik?
5. Adakah setiap klien mesti menghantar parameter kebenaran melalui PAR? Bagaimanakah klien legasi akan berhijrah?
6. Patutkah penyegaran penyemak imbas, navigasi ke belakang, pembatalan, dan percubaan semula rangkaian membaca permintaan yang sama sekali lagi?

Kerangka jawapan 30 saat

Klien menghantar HTTPS POST ke PAR, mengesahkan dirinya, dan mengesahkan parameter URI pengalihan, skop, sumber, dan PKCE. Pelayan mencipta request_uri berentropi tinggi, berjangka hayat pendek, dan terikat dengan klien, lalu mengembalikan JSON. Penyemak imbas kemudiannya hanya menghantar client_id dan request_uri ke titik akhir kebenaran. Titik akhir tersebut masih mengesahkan semula permintaan, state/nonce, persetujuan pengguna, dan PKCE sebelum menggunakan rujukan tersebut. Had kadar, audit, dasar penggunaan sekali sahaja, bendera keserasian, dan metrik kanari mengawal pelancaran.

Jawapan terperinci langkah demi langkah

1. Takrifkan protokol dua lompatan (two-hop)

Lompatan pertama ialah HTTPS POST langsung daripada klien ke PAR dengan badan application/x-www-form-urlencoded. Ia merupakan tempat untuk mengesahkan klien dan mengesahkan client_id, jenis respons, URI pengalihan, skop, penunjuk sumber, state, nonce, dan PKCE. RFC 9126 memerlukan HTTPS untuk PAR dan membenarkan sambungan titik akhir kebenaran.

Lompatan kedua ialah permintaan ejen pengguna (user agent) ke titik akhir kebenaran, yang biasanya hanya membawa client_id dan request_uri. Pelayan kebenaran mengambil semula permintaan yang disimpan dalam lompatan pertama dan bukannya mempercayai parameter sensitif yang dihantar semula oleh penyemak imbas. Ini mengurangkan kebocoran rentetan pertanyaan (query-string), had saiz URL, dan pengubahan tidak sah oleh ejen pengguna.

2. Reka bentuk storan request_uri

Jana request_uri dengan nilai rawak selamat secara kriptografi, jangan sekali-kali menggunakan ID yang bertambah secara berperingkat atau kunci perniagaan yang boleh diramal. Simpan permintaan lengkap, ID klien, masa penciptaan, tamat tempoh, status penggunaan, dan medan audit yang dihancurkan (hashed); ikat rujukan tersebut dengan klien yang menciptanya.

Kekalkan TTL yang singkat dan kembalikannya sebagai expires_in. Rujukan yang telah tamat tempoh mengembalikan invalid_request; rujukan yang tidak diketahui tidak seharusnya mendedahkan sama ada ia pernah wujud. Penggunaan sekali sahaja adalah paling selamat. Jika produk mesti menyokong penyegaran, benarkan tetingkap masa yang singkat dengan bilangan bacaan, pengikatan state/nonce, dan had maksimum yang ketat.

3. Sahkan klien dan permintaan

Sahkan klien di PAR menggunakan peraturan titik akhir token, seperti mTLS atau private_key_jwt. Pengesahan membuktikan klien mana yang menyerahkan permintaan; ia tidak membuktikan bahawa pengguna telah log masuk atau bersetuju dengan skop. Sahkan URI pengalihan yang didaftarkan, skop yang dibenarkan, sumber, dan jenis respons di PAR, kemudian ulangi semakan yang memerlukan konteks pengguna pada waktu kebenaran.

Jika klien menggunakan Objek Permintaan (Request Object) yang ditandatangani, sahkan tandatangan, pengeluar (issuer), khalayak (audience), tamat tempoh, dan medan kritikal di bawah peraturan JAR. PAR ialah tolakan langsung dan kitaran hayat rujukan; JAR ialah penandatanganan atau penyulitan Objek Permintaan. Kedua-duanya boleh digabungkan, tetapi tiada satu pun yang menggantikan yang lain.

4. Letakkan PKCE, state, dan nonce pada lapisan yang betul

PAR masih membawa code_challenge dan kaedahnya; titik akhir token mesti mengesahkan code_verifier semasa menebus kod. state mengikat sesi klien dan mengurangkan CSRF. OIDC nonce mengikat permintaan pengesahan kepada token ID. Kehadiran request_uri bukan sebab untuk membuang kawalan ini atau menganggapnya boleh ditukar ganti.

5. Cegah penukaran (swapping), ulangan (replay), dan pengalihan terbuka (open redirects)

Jika penyerang menggantikan permintaan dengan permintaan yang mereka perolehi, skop atau tahap jaminan boleh berubah. Ikat rujukan kepada klien dan pastikan konteks klien bagi permintaan kebenaran sepadan. Klien menggunakan state dan PKCE yang unik; OIDC menggunakan nonce. Padankan URI pengalihan secara ketat supaya PAR tidak menjadi pintu masuk pengalihan terbuka.

Kembalikan ralat yang eksplisit tetapi tidak mendedahkan perincian (non-enumerating) apabila rujukan yang telah digunakan diguna semula. Log klien, cincangan (hash) rujukan, masa, isyarat risiko, dan hasil untuk mengesan tekaan dan ulangan. Pastikan permintaan kebenaran yang lengkap, penegasan klien (client assertions), dan parameter sumber sensitif berada di luar log akses biasa.

6. Reka bentuk ralat, had, dan ketersediaan

Parameter tidak sah, URI pengalihan yang tidak sepadan, atau tandatangan yang rosak menggunakan ralat OAuth seperti invalid_request. Kaedah yang salah boleh menjadi 405, permintaan yang terlalu besar 413, dan pelanggaran kuota 429. Kenakan had mengikut klien, penyewa, IP, dan storan global supaya penyerang tidak dapat menghabiskan storan PAR.

Apabila PAR tidak tersedia, sama ada klien yang berhijrah boleh berundur (fallback) kepada permintaan kebenaran biasa merupakan keputusan dasar keselamatan. Bagi skop pembayaran atau berisiko tinggi, gagal secara eksplisit daripada melemahkan aliran secara senyap. Hijrahkan klien legasi melalui metadata, kemudian kuat kuasakan require_pushed_authorization_requests secara beransur-ansur.

7. Kendalikan jangka hayat data dan kebolehcerapan

Kekalkan data rujukan hanya untuk tempoh TTL, penggunaan, dan tempoh audit yang diperlukan. Gunakan storan yang disulitkan, kawalan akses, dan peminiman data; jangan salin konteks kebenaran sensitif ke dalam banyak cache. Jejak kejayaan PAR, kegagalan pengesahan, tamat tempoh, penggunaan pendua, kadar 429, kadar rujukan tiada pada waktu kebenaran, dan kegagalan PKCE semasa pertukaran token.

Lakukan kanari aliran biasa dan PAR secara bersebelahan. Bandingkan kadar penyelesaian, kependaman halaman pertama, pengunduran mudah alih, dan amaran keselamatan. Ujian automatik harus merangkumi penggunaan serentak, penukaran rujukan, varian URI pengalihan, penyegaran penyemak imbas, permintaan yang terlalu besar, dan keserasian klien legasi.

Contoh jawapan berkualiti tinggi

Saya akan membahagikan aliran kepada dua lompatan. Klien memanggil PAR melalui HTTPS, mengesahkan dirinya, dan mengesahkan URI pengalihan, skop, sumber, jenis respons, PKCE, state, dan nonce. Pelayan mencipta request_uri berentropi tinggi, berjangka hayat pendek, dan terikat dengan klien, serta hanya mengembalikan rujukan dan expires_in. Penyemak imbas kemudiannya memanggil titik akhir kebenaran dengan ID klien dan rujukan tersebut; pelayan mengambil semula permintaan asal dan melakukan pemeriksaan kebenaran, sesi pengguna, state/nonce, dan PKCE sekali lagi.

Rujukan menyimpan permintaan, pengikatan klien, tamat tempoh, dan status penggunaan, dengan penggunaan sekali sahaja sebagai lalai. Ciri penyegaran menggunakan tetingkap masa pendek, had bacaan, dan audit. JAR mengendalikan penandatanganan atau penyulitan Objek Permintaan; PAR mengendalikan tolakan langsung dan jangka hayat rujukan. Pemadanan URI pengalihan yang ketat menghalang penukaran dan pengalihan terbuka, manakala ralat OAuth serta had bagi setiap klien, IP, dan penyewa menjadikan penyalahgunaan dapat dilihat.

Saya akan melancarkan kanari mengikut metadata klien sambil mengekalkan aliran lama, mengukur kadar penyelesaian, kependaman, tamat tempoh, penggunaan pendua, respons 429, dan kegagalan PKCE. Klien berisiko tinggi tidak berundur secara senyap. Gangguan storan atau lonjakan serangan ulangan akan menghentikan pelancaran dan menterbalikkan bendera penguatkuasaan. Ini mengurangkan kebocoran URL dan pengubahan parameter tanpa mengubah sempadan persetujuan pengguna dan pertukaran kod OAuth.

Kesilapan lazim

• Hanya menyebut "letakkan parameter dalam POST" tanpa pengesahan klien, pengikatan rujukan, atau tamat tempoh.
• Menganggap request_uri sebagai token akses atau menjadikannya ID pangkalan data yang boleh diteka.
• Menganggap PAR secara automatik menghalang serangan ulangan dan meninggalkan penggunaan sekali sahaja, TTL, state, nonce, atau PKCE.
• Mencampuradukkan PAR, JAR, dan PKCE tanpa menjelaskan sempadan perlindungan bagi setiap satu.
• Mengesahkan URI pengalihan hanya di PAR dan mempercayai parameter penyemak imbas pada masa kebenaran.
• Mengabaikan 413, 429, penggunaan serentak, kebocoran cache, dan log sensitif.
• Berundur tanpa syarat kepada kebenaran biasa apabila PAR gagal, sekali gus meluaskan pendedahan skop berisiko tinggi.

Soalan susulan dan respons

Berapa lamakah request_uri patut kekal aktif?

Gunakan TTL yang pendek berdasarkan risiko dan kembalikan expires_in. Padam atau batalkan ia selepas tamat tempoh atau penggunaan; kekalkan hanya medan cincangan, klien, dan hasil yang minimum untuk audit.

Bolehkah penyegaran penyemak imbas menggunakan semula rujukan tersebut?

Lalainya ialah penggunaan sekali sahaja. Jika penyegaran diperlukan, gunakan tetingkap masa yang pendek, had bacaan, dan pengikatan state, nonce, dan sesi klien sambil memantau bacaan pendua. Jangan benarkan penggunaan semula tanpa had.

Mengapakah PKCE masih diperlukan selepas pengesahan klien?

Pengesahan klien mengenal pasti klien yang menyerahkan permintaan. PKCE mengikat penebusan kod kepada pemohon yang memegang penentusah (verifier). Ia kekal penting untuk klien awam dan mudah alih sekiranya kod kebenaran dipintas.

Bolehkah PAR menggantikan JAR?

Tidak. PAR menangani tolakan langsung, penyembunyian parameter penyemak imbas, dan jangka hayat rujukan. JAR menangani penandatanganan atau penyulitan Objek Permintaan. Gabungkan kedua-duanya apabila integriti yang lebih kukuh atau penafian tidak boleh dibuat (non-repudiation) diperlukan.

Bagaimanakah klien legasi patut berhijrah?

Dayakan PAR melalui metadata pelayan kebenaran dan dasar klien, perhatikan sokongan, kemudian kuat kuasakan require_pushed_authorization_requests untuk klien terpilih. Kekalkan laluan legasi yang terhad dan diaudit daripada menukar keseluruhan ekosistem secara membuta tuli.

Bagaimana jika titik akhir PAR menerima trafik yang melimpah (flood)?

Hadkan mengikut klien, penyewa, IP, dan sumber global; hadkan saiz badan dan TTL storan; kembalikan 429; dan pantau kadar kegagalan serta aras storan (storage watermarks). Klien berisiko tinggi tidak boleh diturunkan taraf (downgrade) secara senyap disebabkan oleh tekanan trafik.