Petunjuk dan konteks
Sebuah resource server menerima access token biasa untuk operasi baca, tetapi transfer, perubahan akun pembayaran, dan ekspor data sensitif memerlukan tingkat autentikasi yang lebih kuat. Ketika klien tidak memiliki tingkat tersebut, klien harus menerima tantangan yang dapat ditindaklanjuti, bukan sekadar error 403 yang ambigu. Rancang alur step-up antara resource server, authorization server, dan klien menggunakan RFC 9470.
RFC 9470 mendefinisikan error insufficient_user_authentication untuk tantangan Bearer dan menggunakan acr_values atau konteks autentikasi terkait untuk menyatakan tingkat yang diperlukan. Wawancara ini menguji seluruh siklus mulai dari error API, klaim token, reotorisasi, percobaan ulang yang idempoten, hingga batasan penurunan tingkat.
Hal yang diuji oleh pewawancara
- Membedakan kegagalan otorisasi, autentikasi pengguna yang tidak memadai, dan masa berlaku token yang habis.
- Menyatakan konteks autentikasi yang diperlukan dalam
WWW-Authenticatetanpa mengekspos detail internal risiko. - Mengizinkan klien melakukan reotorisasi dari sebuah tantangan sambil mencegah terjadinya loop dan penurunan tingkat.
- Memverifikasi issuer, audience, scope,
acr,amr, dan klaim waktu pada resource server. - Menangani percobaan ulang, konkurensi, audit, rollback, dan pengalaman pengguna untuk operasi tulis berisiko tinggi.
Pertanyaan klarifikasi
- Operasi mana yang memerlukan tingkat lebih tinggi, dan apakah persyaratannya berupa
acr,amr, atau konfirmasi transaksi? - Apakah access token berupa JWT yang divalidasi secara lokal atau melalui introspeksi? Bisakah resource server melihat konteks autentikasi?
- Apakah klien berupa aplikasi web, seluler, atau server? Apakah PKCE, prompt, dan max_age tersedia?
- Haruskah tantangan bersifat sekali pakai dan terikat pada jumlah nominal, penerima pembayaran, dan nonce?
- Jika layanan otorisasi tidak tersedia, operasi baca mana yang boleh dilanjutkan dan operasi tulis mana yang harus fail closed?
Jawaban 30 detik
Validasi issuer, audience, tanda tangan, masa berlaku, dan scope token terlebih dahulu. Jika scope mencukupi tetapi konteks autentikasi tidak, kembalikan 401 dengan tantangan Bearer WWW-Authenticate menggunakan insufficient_user_authentication serta acr_values dan resource yang diperlukan. Klien mempertahankan intensi dan state, melakukan autentikasi ulang, menerima token yang terikat pada audience, scope, dan konteks yang sama, lalu mencoba ulang sekali. Berikan tantangan TTL yang singkat, percobaan ulang yang dibatasi, dan pengikatan transaksi; jangan pernah menurunkan tingkat operasi berisiko tinggi secara diam-diam.
Jawaban mendalam
1. Menentukan kebijakan autentikasi dan sumber daya
Petakan operasi ke kebijakan autentikasi minimum: tingkat dasar untuk operasi baca, autentikasi tahan phishing untuk perubahan akun pembayaran, dan konfirmasi transaksi untuk transfer. Evaluasi endpoint, metode, tenant, jumlah nominal, dan sinyal risiko daripada menyamakan setiap operasi tulis dengan satu tingkat tetap.
Authorization server mendefinisikan nilai acr yang terdaftar dan metode autentikasi yang dapat diterima. Resource server hanya menerima nilai yang terdaftar; klien tidak dapat mengklaim sendiri tingkat yang lebih tinggi. amr adalah bukti dan tidak menggantikan evaluasi kebijakan terhadap acr.
2. Merancang respons tantangan
Ketika token yang valid tidak memiliki konteks yang diperlukan, kembalikan 401 dan tantangan Bearer dengan error="insufficient_user_authentication". Respons ini dapat mencakup acr_values yang diperlukan, pengenal resource, dan URI error, tetapi tidak boleh mengungkapkan nomor rekening, skor risiko, atau aturan internal.
Tangani konteks yang hilang atau tidak dapat diverifikasi sebagai kondisi tidak memadai. Gunakan error yang berbeda untuk token kedaluwarsa, issuer yang tidak tepercaya, audience yang salah, dan scope yang hilang; jangan menyamarkan setiap kegagalan sebagai step-up.
3. Mengizinkan klien melakukan reotorisasi
Klien mengurai tantangan dan mengikat target awal, acr_values yang diperlukan, resource, dan PKCE ke permintaan otorisasi baru. Klien web menggunakan state dan klien OIDC menggunakan nonce; klien seluler tidak boleh memperlakukan tantangan yang belum diverifikasi sebagai URL otorisasi yang dapat dieksekusi.
Reotorisasi tetap memerlukan autentikasi dan persetujuan authorization server. prompt, max_age, atau kebijakan autentikasi hanyalah sebuah permintaan; server menuliskan acr yang dicapai ke dalam token berdasarkan autentikasi aktual. Klien tidak dapat menandai token telah ditingkatkan secara lokal.
4. Memverifikasi token baru dan intensi awal
Verifikasi tanda tangan, issuer, audience, scope, exp, iat, acr, dan amr yang diperlukan pada token baru. Dengan introspeksi, wajibkan respons authorization server tepercaya dengan konteks yang memadai. Scope saja tidak cukup karena izin dan kekuatan autentikasi adalah dimensi yang terpisah.
Ikat nonce tantangan, digest transaksi, atau ID permintaan otorisasi ke state server untuk tindakan berisiko tinggi agar token dengan autentikasi lebih tinggi tidak dapat dipindahkan ke transaksi lain. Pastikan audience token tepat untuk API target.
5. Mencegah loop, replay, dan penurunan tingkat
Berikan setiap tantangan TTL yang singkat dan ID unik, dengan mencatat digest permintaan, tenant, resource, tingkat yang diperlukan, dan jumlah percobaan ulang. Izinkan satu atau sejumlah kecil percobaan ulang yang dibatasi; gunakan tantangan yang berhasil dan hentikan tantangan yang gagal atau kedaluwarsa.
Tolak acr_values yang lebih rendah, substitusi resource atau audience, dan fallback ke token biasa setelah waktu tunggu step-up habis. Gunakan kunci idempotensi untuk transfer sehingga percobaan ulang autentikasi tidak menduplikasi efek samping.
6. Menangani ketersediaan dan batasan error
Jika layanan otorisasi atau introspeksi tidak tersedia, operasi baca berisiko rendah dapat menggunakan cache singkat; operasi tulis, pembayaran, dan perubahan izin harus fail closed secara default. Error tantangan tidak boleh mengungkapkan metode autentikasi atau status akun. Log menyimpan ID tantangan, issuer, hasil, dan latensi.
Lacak tingkat konteks yang tidak memadai, penyelesaian tantangan, loop, masa kedaluwarsa, replay, kegagalan PKCE, penolakan oleh acr, dan efek bisnis duplikat. Segmentasikan peringatan berdasarkan resource dan tenant untuk memisahkan error kebijakan dari serangan.
7. Melakukan peluncuran dan rollback dengan aman
Aktifkan step-up pada satu API dan tenant terlebih dahulu, lalu bandingkan respons 401, penyelesaian, latensi, masukan dukungan, dan penolakan risiko tinggi. Klien yang tidak memahami tantangan menerima error yang terdokumentasi dan panduan SDK; token biasa tidak diterima secara diam-diam untuk semua pihak.
Rollback hanya menonaktifkan kebijakan resource yang belum diaktifkan serta mempertahankan state tantangan dan audit untuk transaksi yang aktif. Jika konteks bocor, efek samping terduplikasi, atau loop muncul, jeda peluncuran, cabut kebijakan, dan periksa kembali pengikatan token.
Contoh jawaban
Saya akan mendefinisikan tingkat autentikasi minimum untuk setiap operasi. Setelah memvalidasi token, resource server mengembalikan 401 dengan insufficient_user_authentication serta acr_values, resource, dan URI error minimal ketika scope mencukupi tetapi acr atau amr tidak memadai. Klien mempertahankan intensi dan menggunakan state, nonce, dan PKCE untuk reotorisasi; authorization server menerbitkan token yang konteksnya mencerminkan autentikasi aktual.
Resource server memverifikasi kembali issuer, audience, scope, waktu, acr, dan amr yang diperlukan, mengikat ID tantangan atau digest transaksi ke state server. Tantangan berumur pendek, sekali pakai, dan dibatasi percobaan ulangnya; tingkat yang lebih rendah, audience baru, dan fallback tanpa syarat akan ditolak. Operasi tulis berisiko tinggi fail closed selama pemadaman autentikasi, dan transfer menggunakan kunci idempotensi.
Kesalahan umum
- Mengembalikan error umum 403 atau 401 alih-alih tantangan
insufficient_user_authenticationyang dapat ditindaklanjuti. - Memeriksa scope tetapi tidak memeriksa issuer, audience,
acr,amr, dan klaim waktu. - Membiarkan klien mengklaim sendiri
acryang lebih tinggi, atau menurunkannya setelah menerima tantangan. - Memperlakukan tantangan sebagai URL otorisasi yang tidak diverifikasi dan melewatkan state, nonce, atau PKCE.
- Mencoba ulang tanpa batas atau menghilangkan pengikatan transaksi, sehingga memungkinkan penggunaan ulang token di berbagai operasi.
- Menurunkan tingkat transfer atau perubahan izin secara diam-diam saat autentikasi tidak tersedia.
- Mencatat informasi akun, skor risiko, atau token lengkap ke dalam log.
Pertanyaan lanjutan dan jawaban
Mengapa mengembalikan 401 ketika scope mencukupi tetapi acr tidak?
Scope menyatakan apa yang boleh diakses oleh token; acr menyatakan bagaimana pengguna diautentikasi. Suatu resource dapat mewajibkan keduanya, sehingga klien memerlukan langkah otorisasi baru.
Apa saja yang termasuk dalam sebuah tantangan?
Hanya tingkat autentikasi yang diperlukan, pengenal resource, URI error, dan pengenal tantangan berumur pendek yang dibutuhkan untuk tindakan klien. Simpan detail akun, jumlah nominal, risiko internal, dan metode di sisi server.
Bisakah klien memanggil token endpoint secara langsung untuk melakukan upgrade?
Tidak. Klien harus mengikuti tantangan melalui autentikasi dan persetujuan authorization server. Server, bukan klien, yang menegaskan acr yang dicapai di dalam token.
Bagaimana cara mencegah token yang telah ditingkatkan digunakan untuk transfer lain?
Ikat audience, resource, ID tantangan, atau digest transaksi ke state server sekali pakai, dan gunakan kunci idempotensi untuk transfer tersebut.
Bagaimana jika introspeksi tidak tersedia untuk sementara?
Klasifikasikan berdasarkan risiko resource. Bukti cache singkat dapat melayani operasi baca biasa; pembayaran dan perubahan izin harus fail closed ketika konteks tidak dapat dikonfirmasi.
Bagaimana Anda mendukung klien lama yang tidak memahami tantangan?
Publikasikan error yang terdokumentasi dan panduan migrasi SDK, lalu aktifkan per tenant. Operasi berisiko tinggi tetap mempertahankan persyaratannya hingga migrasi selesai.