Maklum balas dan skop
Anda memiliki API OAuth yang digunakan oleh klien mudah alih dan pelayar. Pelayan sumber pada masa ini hanya mengesahkan token akses Bearer; satu kebocoran log boleh membolehkan penyerang memainkan semula (replay) permintaan semasa token masih sah. Reka bentuk skim DPoP (Demonstrating Proof-of-Possession), termasuk pelayan kebenaran, klien, pelayan sumber, dan tingkah laku apabila DPoP tidak tersedia.
Ini ialah soalan seni bina keselamatan backend, bukan kuiz konfigurasi vendor. RFC 9449 mengikat token akses kepada kunci awam klien dan memerlukan setiap panggilan membawa bukti yang terikat pada kaedah HTTP dan URI. RFC 9700 menambah panduan keselamatan OAuth semasa seperti mengelakkan aliran yang lemah dan menggunakan PKCE.
Perkara yang sedang diuji oleh penemu bual
Jawapan yang kukuh bermula dengan mod kegagalan token Bearer: sesiapa sahaja yang memegang rentetan tersebut boleh menggunakannya, jadi token yang dicuri tidak dapat dibezakan daripada permintaan yang sah. Ia kemudiannya memberikan aliran hujung ke hujung: klien mencipta kunci, titik akhir token mengesahkan bukti DPoP dan mengikat kunci awam, dan pelayan sumber menyemak tandatangan, kaedah, URI, cincangan token, dan tetingkap masa.
Penemu bual juga menjangkakan pelan untuk ulang tayang jti, nonce pelayan, kehilangan kunci, penulisan semula URI oleh proksi, token penyegaran, klien lama, dan telemetri. Sekadar menyatakan "tandatangani JWT" adalah tidak mencukupi: tandatangan JWT biasa membuktikan integriti pengeluar, bukan bahawa pemanggil masih memiliki kunci peribadi yang digunakan semasa pengeluaran.
Soalan untuk dijelaskan terlebih dahulu
Klien dan model ancaman
Sahkan sama ada klien ialah SPA pelayar, aplikasi mudah alih natif, atau aplikasi pelayan. Sama ada kunci peribadi boleh berada dalam storan bersandarkan perkakasan dan sama ada setiap pemasangan mendapat kuncinya sendiri akan mengubah kitaran hayat. Tanya sama ada penyerang boleh membaca log, proksi, storan pelayar, atau fail peranti, dan sama ada mereka boleh memintas permintaan dalam masa nyata.
Sempadan pelayan sumber
Sahkan get laluan, penamatan TLS, dan pemajuan dalaman. htu DPoP mesti sepadan dengan semantik URI yang disahkan oleh pelayan sumber. Jika get laluan menulis semula laluan, tentukan pengkanonikan dan pengepala pemajuan yang dipercayai; jangan biarkan klien menandatangani satu alamat sementara bahagian belakang mengesahkan alamat yang lain.
Kekangan ketersediaan dan migrasi
Tanya sama ada klien Bearer legasi mesti terus berfungsi, sama ada tempoh dwi-timbunan (dual-stack) yang singkat boleh diterima, dan sama ada log masuk dan penyegaran menggunakan pelayan kebenaran yang sama. Jika peraturan atau API bernilai tinggi memerlukan kekangan penghantar yang kukuh, jadikan DPoP mandatori. Untuk sumber berisiko rendah, lakukan migrasi melalui rundingan keupayaan dan pelancaran yang terukur.
Rangka kerja jawapan 30 saat
"Saya akan mereka bentuk DPoP sebagai protokol tiga pihak. Klien menjana pasangan kunci bagi setiap pemasangan dan menghantar bukti DPoP sekali guna semasa permintaan token. Pelayan kebenaran mengesahkannya dan mengikat cnf.jkt token akses kepada kunci awam. Setiap panggilan API membawa JWT DPoP yang baharu; pelayan sumber menyemak tandatangannya, htm, htu, iat, jti yang unik, ath, dan cnf.jkt milik token, dengan nonce dan tetingkap masa yang singkat untuk mengurangkan ulang tayang. Kunci peribadi yang hilang akan membatalkan token yang terikat. Klien legasi mendapat laluan Bearer dengan had masa hanya untuk sumber yang jelas berisiko rendah manakala operasi bernilai tinggi beralih kepada DPoP mandatori."
Penyelesaian langkah demi langkah
Langkah 1: Cipta kunci dan ikat kebenaran
Pada larian pertama, klien mencipta pasangan kunci asimetrik dan menyimpan kunci peribadi dalam storan peranti yang selamat. Ia menghantar kunci awam dalam JWK yang dibawa oleh bukti DPoP semasa meminta token. Pelayan kebenaran mengesahkan tandatangan, jenis, dan masa bukti, kemudian mengikat data pengesahan token kepada cap jari (thumbprint) JWK kunci awam. Dengan aliran kod kebenaran, tetap gunakan panduan PKCE RFC 9700: DPoP membuktikan pemilikan token dan tidak menggantikan perlindungan kod.
Langkah 2: Jana bukti bagi setiap permintaan
Bagi setiap permintaan, klien mencipta JWT baharu yang mengandungi sekurang-kurangnya jti, htm, htu, dan iat, kemudian menandatanganinya dengan kunci peribadi yang terikat. Ia meletakkan cincangan token akses dalam ath, membolehkan pelayan sumber mengesahkan bahawa bukti menyasarkan token ini dan bukannya token lain yang ditandatangani oleh kunci yang sama. Bukti dimasukkan ke dalam pengepala DPoP, dan token akses menggunakan skema kebenaran DPoP dan bukannya Bearer.
Langkah 3: Sahkan dalam urutan tetap
Pelayan sumber terlebih dahulu mengehadkan algoritma dan jenis JWK, kemudian mengesahkan tandatangan JWT, format kunci, tetingkap masa, kaedah, dan URI. Ia mencincang token akses dan membandingkan hasilnya dengan ath; ia membaca cnf.jkt daripada token dan membandingkannya dengan cap jari kunci bukti. Ia kemudian menyemak sama ada jti telah muncul dalam tetingkap semasa sebelum menggunakan kebenaran skop, audiens, dan sumber biasa.
Langkah 4: Kendalikan nonce dan ulang tayang
Pelayan boleh mengeluarkan nonce untuk sumber berisiko tinggi, memerlukan klien menyertakannya dalam bukti seterusnya. Penyahduplikasian jti diperlukan dalam tetingkap penerimaan. Cache nod tunggal berfungsi untuk penggunaan kecil; pelayan sumber berbilang tika memerlukan cache kongsi yang tamat tempoh, atau mesti menerima risiko pendua tetingkap pendek secara eksplisit dan merekodkannya sebagai peristiwa keselamatan. Telemetri penolakan harus membezakan tamat tempoh, tandatangan tidak sah, ketidakpadanan cap jari, dan ketiadaan nonce tanpa mendedahkan bahan kunci.
Langkah 5: Reka bentuk giliran, pembatalan, dan sandaran
Jika peranti hilang, kunci peribadi terdedah, atau pelayan mengesan penyalahgunaan, batalkan token akses dan penyegaran yang dikaitkan dengan cap jari tersebut dan minta kebenaran semula. Giliran kunci tidak boleh menjadi penggantian senyap di pihak klien sahaja: kunci awam baharu memerlukan pengikatan kebenaran baharu. Semasa migrasi, pelayan sumber boleh menerima kedua-dua skema, tetapi operasi tulis bernilai tinggi harus mempunyai dasar mandatori-DPoP yang berasingan supaya keserasian tidak pernah menjadi lalai keselamatan.
Langkah 6: Bandingkan mTLS dengan Bearer biasa
mTLS meletakkan bukti pada lapisan sijil klien TLS dan sesuai untuk sistem pelayan-ke-pelayan dengan operasi sijil yang matang. DPoP berfungsi pada lapisan aplikasi dan sesuai untuk klien mudah alih dan pelayar, tetapi ia menambah operasi bukti, nonce, jti, dan storan kunci. Bearer biasa adalah paling mudah untuk digunakan tetapi tidak dapat menentang ulang tayang selepas rentetan token disalin. Pilih berdasarkan keupayaan klien, topologi proksi, pematuhan, dan kos operasi dan bukannya mendayakan DPoP secara membuta tuli untuk setiap titik akhir.
Contoh jawapan berkualiti tinggi
Saya akan bermula dengan model ancaman: kebocoran log, proksi, atau storan klien boleh mendedahkan token akses, yang membolehkan penyerang memanggil API semasa tempoh sahnya. Tempoh tamat yang lebih singkat menyempitkan tetingkap tersebut tetapi tidak membuktikan bahawa pemanggil ialah klien asal.
Klien mencipta pasangan kunci bagi setiap pemasangan dan melindungi kunci peribadi. Semasa pertukaran kod kebenaran, saya memerlukan PKCE dan bukti DPoP; pelayan kebenaran mengesahkan bukti dan mengikat cnf.jkt token kepada kunci awam. Di pelayan sumber, saya mengesahkan tandatangan bukti, htm, htu, iat, jti, ath, dan nonce dalam urutan tetap, kemudian membandingkan cap jari kunci bukti dengan pengikatan token. Sebarang ketidakpadanan dianggap tidak dibenarkan dan dikelaskan dalam metrik keselamatan.
Saya menyimpan nilai jti dalam cache penyahduplikasian kongsi yang disandarkan TTL untuk penggunaan berbilang tika. Operasi tulis berisiko tinggi memerlukan nonce dan DPoP. Semasa migrasi, operasi baca berisiko rendah boleh menjadi dwi-timbunan, tetapi tarikh akhir terikat pada versi klien dan risiko sumber. Kunci yang hilang akan membatalkan tokennya dan memulakan kebenaran baharu; sandaran Bearer tidak pernah berkongsi laluan operasi tulis bernilai tinggi. Akhir sekali, saya menjalankan ujian integrasi untuk bukti palsu, ulang tayang jti lama, perubahan URI, cincangan token yang salah, nonce yang tamat tempoh, dan penulisan semula proksi, kemudian memantau kadar penolakan, percubaan semula nonce, dan cap jari yang tidak normal untuk membuktikan bahawa ulang tayang disekat.
Kesilapan biasa
- Kesilapan: Hanya menandatangani token akses sebagai JWT. → Sebab ia gagal: Tandatangan membuktikan integriti pengeluar tetapi bukan pemilikan kunci peribadi klien. → Penyelesaian: Ikat
cnf.jktdan sahkan bukti DPoP baharu pada setiap permintaan. - Kesilapan: Menggunakan semula satu bukti DPoP. → Sebab ia gagal: Penyerang boleh memainkan semula keseluruhan permintaan kerana
jtidan semakan masa tidak dapat membezakannya. → Penyelesaian: Janajtibaharu bagi setiap permintaan dan lakukan penyahduplikasian dalam tetingkap penerimaan, sambil menambah nonce jika perlu. - Kesilapan: Mengesahkan DPoP hanya di get laluan manakala perkhidmatan dalaman mempercayai pengepala pengguna yang tidak terikat. → Sebab ia gagal: Pemajuan boleh kehilangan kaedah, URI, atau pengikatan token dan membiarkan identiti palsu lolos. → Penyelesaian: Hantarkan hasil pengesahan yang dinormalkan merentasi sempadan yang dipercayai dan hadkan pihak yang boleh menetapkannya.
- Kesilapan: Berbalik kepada Bearer pada setiap ralat pengesahan. → Sebab ia gagal: Penyerang boleh mencetuskan ralat DPoP secara sengaja untuk mencapai laluan yang paling lemah. → Penyelesaian: Benarkan sandaran dengan had masa hanya untuk klien legasi berdaftar dan sumber berisiko rendah.
Soalan susulan dan respons
Soalan susulan 1: Bagaimanakah anda menyahduplikasi jti merentas wilayah?
Pilih ketekalan mengikut risiko sumber. Operasi tulis bernilai tinggi boleh menggunakan storan kongsi merentas wilayah dan menanggung kos satu perjalanan pergi balik tambahan; operasi baca berisiko rendah boleh menggunakan cache wilayah dan tetingkap pendek, merekodkan pendua tanpa mengorbankan ketersediaan. Dalam mana-mana reka bentuk, tuliskan tetingkap, tingkah laku kegagalan, dan kadar pendua ke dalam SLO.
Soalan susulan 2: Bagaimana jika XSS membaca kunci peribadi pelayar?
DPoP tidak dapat membaiki persekitaran pelaksanaan klien yang dikawal sepenuhnya. Utamakan kunci yang tidak boleh dieksport, dasar keselamatan kandungan yang ketat, token jangka hayat pendek, dan giliran penyegaran; batalkan pengikatan apabila cap jari berkelakuan tidak normal. Nyatakan sempadan perlindungan dengan jelas: DPoP menyasarkan token yang disalin apabila kunci peribadi tidak disalin, bukan setiap bentuk pengambilalihan titik akhir.
Soalan susulan 3: Proksi menukar URI. Bagaimanakah anda mengesahkan htu?
Tentukan pemetaan daripada URI kanonikal luaran kepada laluan dalaman, dan hanya benarkan proksi yang dipercayai memberikan skema, hos, dan laluan asal yang disahkan. Pelayan sumber menggunakan pengkanonikan yang sama sebelum perbandingan dan menolak pengepala pemajuan yang tidak disahkan dan dikawal oleh klien. Jika tiada pemetaan yang dipercayai wujud, tamatkan DPoP di sempadan dan keluarkan identiti dalaman jangka hayat pendek dan bukannya meneka URI asal.
Soalan susulan 4: Klien legasi hanya boleh menghantar Bearer. Bolehkah anda menyokong mereka selama-lamanya?
Keserasian kekal bukanlah satu reka bentuk keselamatan. Tetapkan tarikh akhir migrasi mengikut versi klien, risiko pengguna, dan jenis sumber; wajibkan DPoP terlebih dahulu untuk operasi tulis bernilai tinggi, kembalikan ralat peningkatan yang boleh diambil tindakan, dan pantau trafik baki. Kekalkan laluan Bearer terhad hanya apabila semakan risiko mewajarkannya dan menambah pengikatan peranti atau had kadar.