Soalan dan senario
Penemu duga memberikan draf Kumpulan Kerja IETF OAuth iaitu “OAuth 2.0 Attestation-Based Client Authentication” dan bertanya bagaimana tikaan klien (client instance) membawa pengesahan (attestation) yang terikat pada kunci, kemudian membandingkannya dengan client_secret dan mTLS. Soalan ini menguji kematangan protokol, identiti peranti, dan pertimbangan pelaksanaan (deployment judgment).
Perkara yang diuji oleh penemu duga
- Memisahkan antara klien OAuth, tikaan klien, pengeluar pengesahan (attestation issuer), dan Pelayan Kebenaran (Authorization Server).
- Menerangkan pengikatan kunci (key binding), khalayak (audience), jangka hayat, dan pertahanan main semula tanpa menganggap draf sebagai piawaian yang telah dimuktamadkan.
- Membandingkan rahsia kongsi, mTLS, dan pengesahan berdasarkan punca kepercayaan (trust roots), operasi, dan mod kegagalan.
Soalan penjelasan sebelum menjawab
Jelaskan versi draf, sama ada klien merupakan aplikasi mudah alih, peranti perkakasan, atau pelayan, siapa yang mengeluarkan pengesahan, dan punca pengesahan mana yang dipercayai oleh Pelayan Kebenaran. Jelaskan model ancaman: kunci disalin, klien diubah suai, pemindahan token, atau pengesahan klien sulit (confidential-client) biasa.
Kerangka jawapan 30 saat
Saya akan menyatakan bahawa ini ialah Draf Internet IETF OAuth dan medan-medannya bergantung pada versi sasaran. Idea terasnya adalah untuk tikaan klien mengemukakan pengesahan yang terikat pada kuncinya; Pelayan Kebenaran mengesahkan rantaian, khalayak, jangka hayat, dan bukti pemilikan kunci sebelum menerima pengesahan OAuth. Ia menyatakan kepercayaan pada peringkat tikaan dengan lebih baik berbanding client_secret yang dikongsi, tetapi menambah operasi pengeluar, pemutaran, pembatalan, dan privasi. mTLS mempunyai laluan kepercayaan yang berbeza dan sesuai untuk persekitaran dengan PKI sedia ada.
Jawapan mendalam langkah demi langkah
- Asingkan pendaftaran klien logik daripada tikaan klien. Tikaan menjana atau memegang kunci, dan pengesahan menyatakan bagaimana kunci tersebut berkaitan dengan sifat tikaan.
- Klien menghantar pengesahan dan bahan pengikatan kunci bersama permintaan pengesahan OAuth. Pelayan mengesahkan tandatangan, rantaian, khalayak, tetingkap masa, nonce atau kekangan main semula yang lain, serta bukti bahawa permintaan itu dibuat dengan kunci peribadi.
- Selepas pengesahan, Pelayan Kebenaran menggabungkan status tikaan, ID klien, dasar, dan isyarat risiko sebelum kebenaran OAuth normal atau pengeluaran token. Pengesahan bukanlah satu kebenaran (authorization).
- Bezakan pengesahan yang telah tamat tempoh, pengeluar yang tidak dipercayai, ketidakpadanan kunci, penggunaan semula nonce, dan pembatalan dengan ralat yang tidak mendedahkan butiran sensitif.
- Kendalikan punca kepercayaan, pemutaran pengeluar, senarai pembatalan, penggantian peranti, dan cache pengesahan luar talian. Rekodkan versi dan sebab supaya penolakan kekal boleh dijelaskan.
- Kumpulkan hanya sifat tikaan yang diperlukan oleh dasar. Elakkan daripada mendedahkan pengecam peranti yang stabil kepada pelayan sumber yang tidak berkaitan, dan pastikan pengesahan attestation dipisahkan daripada kebenaran sumber.
client_id = mobile-app
client_instance_key = K_instance
attestation = Sign_issuer(K_instance, audience=as.example, exp=t+300)
request_proof = Sign_K_instance(attestation, nonce, oauth_request_hash)Contoh jawapan berkualiti tinggi
Saya akan menyatakan status draf dan versinya terlebih dahulu, kemudian memisahkan klien logik daripada tikaan. Tikaan memegang kunci dan mengemukakan pengesahan pengeluar yang dipercayai yang terikat pada kunci tersebut. Pelayan Kebenaran mengesahkan rantaian tandatangan, khalayak, jangka hayat, nonce, dan pemilikan kunci peribadi, kemudian menggunakan hasilnya sebagai input pengesahan identiti. Pengesahan tidak memberikan skop. Berbanding dengan client_secret, ia mengurangkan penyalinan rahsia kongsi; berbanding dengan mTLS, ia boleh disesuaikan dengan tikaan aplikasi tetapi memerlukan operasi pengeluar, pemutaran, pembatalan, dan privasi. Sebelum pelancaran, saya akan mendokumenkan punca kepercayaan, ralat, cache main semula, aliran penggantian, dan keserasian versi draf dan bukannya mengekod keras (hard-coding) medan eksperimen sebagai protokol kekal.
Kesilapan lazim
- Memanggil Draf Internet sebagai RFC yang telah diterbitkan atau piawaian yang boleh saling beroperasi.
- Menganggap bahawa pengesahan memberikan kebenaran atau skop yang lebih tinggi secara automatik.
- Hanya mengesahkan tandatangan pengeluar, bukan pemilikan kunci permintaan, khalayak, atau nonce.
- Mengabaikan pembatalan, penggantian peranti, perbezaan masa jam (clock skew), dan cache luar talian.
- Menjejaki pengguna dengan pengecam peranti yang stabil tanpa peminimuman atau sempadan penyewa (tenant boundaries).
Soalan susulan dan jawapan
Apakah perbezaan utama berbanding client_secret?
client_secret biasanya merupakan kelayakan kongsi yang boleh disalin dan tidak dapat mengenal pasti tikaan tertentu. Pengesahan mengikat kunci tikaan pada pernyataan pengeluar, meningkatkan pertimbangan pada peringkat tikaan dengan kos pengurusan punca kepercayaan dan kitaran hayat.
Apakah perbezaan utama berbanding mTLS?
mTLS menggunakan TLS bersama (mutual TLS) dan PKI sijil untuk membuktikan klien pada lapisan sambungan. Pengesahan ialah input pengesahan identiti OAuth yang boleh berfungsi merentasi pelbagai laluan pengangkutan, dengan model pengeluar, penentusahan, dan privasi yang berbeza.
Bagaimanakah anda menghalang main semula (replay) pengesahan?
Ikat hash permintaan, khalayak, jangka hayat yang pendek, dan nonce pelayan, simpan nonce atau pengecam pengesahan yang telah digunakan dalam cache, serta sahkan pemilikan kunci peribadi yang terikat.
Bagaimanakah anda melancarkan draf yang kerap berubah?
Jadikan versi draf, algoritma, dan pengesah sebagai konfigurasi eksplisit. Lakukan ujian kenari (canary) dalam persekitaran keserasian, kekalkan sandaran pengesahan tradisional serta metrik, kemudian perketatkan keperluan secara beransur-ansur; jangan sekali-kali membekukan medan yang belum selesai sebagai protokol kekal.