Wawancara Umum: Bagaimana Anda Menjelaskan OAuth 2.0 Attestation-Based Client Authentication?

Pertanyaan dan skenario

Pewawancara memberikan draf IETF OAuth Working Group “OAuth 2.0 Attestation-Based Client Authentication” dan menanyakan bagaimana sebuah instans klien membawa atestasi yang terikat kunci (key-bound attestation), lalu membandingkannya dengan client_secret dan mTLS. Pertanyaan ini menguji kematangan protokol, identitas perangkat, dan pertimbangan implementasi.

Apa yang sedang diuji oleh pewawancara

• Memisahkan antara klien OAuth, instans klien, penerbit atestasi (attestation issuer), dan Server Otorisasi (Authorization Server).
• Menjelaskan pengikatan kunci (key binding), audience, masa berlaku (lifetime), dan pertahanan replay tanpa menyebut draf sebagai standar final.
• Membandingkan shared secret, mTLS, dan atestasi berdasarkan trust root, operasional, dan mode kegagalan.

Pertanyaan klarifikasi sebelum menjawab

Klarifikasi versi draf, apakah klien berupa aplikasi seluler, perangkat keras, atau server, siapa yang menerbitkan atestasi, dan trust root verifikasi mana yang dipercayai oleh Server Otorisasi. Klarifikasi model ancamannya: kunci yang disalin, klien yang dimodifikasi, pemindahan token, atau autentikasi confidential-client biasa.

Kerangka jawaban 30 detik

Saya akan menyatakan bahwa ini adalah Internet-Draft IETF OAuth dan bidang-bidangnya bergantung pada versi target. Gagasan utamanya adalah instans klien mengirimkan atestasi yang terikat pada kuncinya; Server Otorisasi memverifikasi rantai sertifikat, audience, masa berlaku, dan bukti kepemilikan kunci sebelum menerima autentikasi OAuth. Ini mengekspresikan kepercayaan tingkat instans lebih baik daripada client_secret bersama, tetapi menambah operasional penerbit, rotasi, pencabutan (revocation), dan privasi. mTLS memiliki jalur kepercayaan yang berbeda dan cocok untuk lingkungan dengan PKI yang sudah ada.

Jawaban mendalam langkah demi langkah

1. Pisahkan pendaftaran klien logis dari instans klien. Instans menghasilkan atau memegang kunci, dan atestasi menyatakan bagaimana kunci tersebut berkaitan dengan properti instans.
2. Klien mengirimkan atestasi dan materi pengikatan kunci bersama permintaan autentikasi OAuth. Server memverifikasi tanda tangan, rantai, audience, jendela waktu, nonce atau batasan replay lainnya, serta bukti bahwa permintaan dibuat menggunakan kunci privat.
3. Setelah verifikasi, Server Otorisasi menggabungkan status instans, client ID, kebijakan, dan sinyal risiko sebelum otorisasi OAuth atau penerbitan token normal. Atestasi bukanlah otorisasi.
4. Bedakan atestasi yang kedaluwarsa, penerbit yang tidak tepercaya, ketidakcocokan kunci, penggunaan ulang nonce, dan pencabutan dengan kesalahan yang tidak mengungkap detail sensitif.
5. Kelola trust root, rotasi penerbit, daftar pencabutan, penggantian perangkat, dan cache verifikasi offline. Catat versi dan alasan penolakan agar tetap dapat dijelaskan.
6. Kumpulkan hanya properti instans yang diwajibkan oleh kebijakan. Hindari mengekspos pengenal perangkat yang stabil ke server sumber daya yang tidak perlu, dan pisahkan verifikasi atestasi dari otorisasi sumber daya.

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 jawaban berkualitas tinggi

Pertama, saya akan menyatakan status draf dan versinya, lalu memisahkan klien logis dari sebuah instans. Instans tersebut memegang kunci dan mengirimkan atestasi penerbit tepercaya yang terikat pada kunci tersebut. Server Otorisasi memverifikasi rantai tanda tangan, audience, masa berlaku, nonce, dan kepemilikan kunci privat, lalu menggunakan hasilnya sebagai input autentikasi. Atestasi tidak memberikan scope. Dibandingkan dengan client_secret, ini mengurangi penyalinan shared-secret; dibandingkan dengan mTLS, ini dapat cocok untuk instans aplikasi tetapi memerlukan operasi penerbit, rotasi, pencabutan, dan privasi. Sebelum peluncuran, saya akan mendokumentasikan root, kesalahan, cache replay, alur penggantian, dan kompatibilitas versi draf alih-alih melakukan hard-coding pada field eksperimental sebagai protokol permanen.

Kesalahan umum

• Menyebut Internet-Draft sebagai RFC yang sudah diterbitkan atau standar yang dapat dioperasikan secara universal.
• Menganggap atestasi secara otomatis memberikan otorisasi atau scope yang lebih tinggi.
• Hanya memverifikasi tanda tangan penerbit, bukan kepemilikan kunci permintaan, audience, atau nonce.
• Mengabaikan pencabutan, penggantian perangkat, clock skew, dan cache offline.
• Melacak pengguna dengan pengenal perangkat yang stabil tanpa minimalisasi atau batasan tenant.

Pertanyaan lanjutan dan jawabannya

Apa perbedaan utama dari client_secret?

client_secret biasanya merupakan kredensial bersama yang dapat disalin dan tidak dapat mengidentifikasi instans tertentu. Atestasi mengikat kunci instans ke pernyataan penerbit, meningkatkan penilaian tingkat instans dengan konsekuensi biaya manajemen trust-root dan siklus hidup.

Apa perbedaan utama dari mTLS?

mTLS menggunakan mutual TLS dan sertifikat PKI untuk membuktikan klien pada lapisan koneksi. Atestasi adalah input autentikasi OAuth yang dapat bekerja di berbagai jalur transport, dengan model penerbit, verifikasi, dan privasi yang berbeda.

Bagaimana Anda mencegah replay atestasi?

Ikat hash permintaan, audience, masa berlaku yang singkat, dan nonce server, simpan nonce atau pengenal atestasi yang telah digunakan dalam cache, serta verifikasi kepemilikan kunci privat yang terikat.

Bagaimana Anda meluncurkan draf yang masih terus berubah?

Jadikan versi draf, algoritma, dan verifier sebagai konfigurasi eksplisit. Lakukan deployment canary di lingkungan kompatibilitas, pertahankan fallback autentikasi tradisional dan metrik, lalu perketat persyaratan secara bertahap; jangan pernah membekukan field yang belum final sebagai protokol permanen.