Temu duga Backend: Bagaimanakah anda mereka bentuk cabaran pengesahan step-up OAuth 2.0?

Gesaan dan konteks

Pelayan sumber menerima token akses biasa untuk operasi baca, tetapi pemindahan, perubahan akaun pembayaran dan eksport sensitif memerlukan tahap pengesahan yang lebih kukuh. Apabila klien kekurangan tahap tersebut, ia harus menerima cabaran yang boleh diambil tindakan dan bukannya ralat 403 yang samar-samar. Reka bentuk aliran step-up antara pelayan sumber, pelayan kebenaran dan klien menggunakan RFC 9470.

RFC 9470 mentakrifkan ralat insufficient_user_authentication untuk cabaran Bearer dan menggunakan acr_values atau konteks pengesahan berkaitan untuk menyatakan tahap yang diperlukan. Temu duga ini menguji kitaran lengkap merentasi ralat API, tuntutan (claims) token, kebenaran semula, percubaan semula idempoten dan sempadan penurunan taraf.

Perkara yang diuji oleh penemu duga

Membezakan kegagalan kebenaran, pengesahan pengguna yang tidak mencukupi dan tamat tempoh token.
Menyatakan konteks pengesahan yang diperlukan dalam WWW-Authenticate tanpa mendedahkan butiran dalaman risiko.
Membenarkan klien mendapatkan kebenaran semula daripada cabaran sambil menghalang gelung (loops) dan penurunan taraf.
Mengesahkan pengeluar (issuer), khalayak (audience), skop, acr, amr dan tuntutan masa pada pelayan sumber.
Mengendalikan percubaan semula, konkurensi, audit, rollback dan pengalaman pengguna untuk operasi tulis berisiko tinggi.

Soalan penjelasan

Operasi manakah yang memerlukan tahap lebih tinggi, dan adakah keperluannya berupa acr, amr, atau pengesahan transaksi?
Adakah token akses merupakan JWT yang disahkan secara setempat atau melalui introspeksi? Bolehkah pelayan sumber melihat konteks pengesahan?
Adakah klien merupakan aplikasi web, mudah alih atau pelayan? Adakah PKCE, prompt dan max_age tersedia?
Patutkah cabaran bersifat sekali guna dan terikat pada amaun, penerima bayaran serta nonce?
Jika perkhidmatan kebenaran tidak tersedia, operasi baca manakah yang boleh diteruskan dan operasi tulis manakah yang mesti fail closed?

Jawapan 30 saat

Sahkan pengeluar, khalayak, tandatangan, tamat tempoh dan skop token terlebih dahulu. Jika skop mencukupi tetapi konteks pengesahan tidak, kembalikan 401 dengan cabaran Bearer WWW-Authenticate menggunakan insufficient_user_authentication serta acr_values dan sumber yang diperlukan. Klien mengekalkan niat dan keadaan (state), mengesahkan semula, menerima token yang terikat pada khalayak, skop dan konteks yang sama, serta mencuba semula sekali. Berikan cabaran TTL yang pendek, percubaan semula terhad dan pengikatan transaksi; jangan sekali-kali menurunkan taraf operasi berisiko tinggi secara senyap.

Jawapan mendalam

1. Tentukan dasar pengesahan dan sumber

Petakan operasi kepada dasar pengesahan minimum: tahap asas untuk operasi baca, pengesahan tahan pancingan data (phishing-resistant) untuk perubahan akaun pembayaran dan pengesahan transaksi untuk pemindahan. Nilaikan titik akhir, kaedah, penyewa (tenant), amaun dan isyarat risiko dan bukannya menyamakan setiap operasi tulis dengan satu tahap tetap.

Pelayan kebenaran mentakrifkan nilai acr yang didaftarkan dan kaedah pengesahan yang boleh diterima. Pelayan sumber hanya menerima nilai yang didaftarkan; klien tidak boleh menegaskan tahap yang lebih tinggi secara kendiri. amr ialah bukti dan tidak menggantikan penilaian dasar bagi acr.

2. Reka bentuk respons cabaran

Apabila token yang sah kekurangan konteks yang diperlukan, kembalikan 401 dan cabaran Bearer dengan error="insufficient_user_authentication". Ia boleh merangkumi acr_values yang diperlukan, pengecam sumber dan URI ralat, tetapi tidak boleh mendedahkan nombor akaun, skor risiko atau peraturan dalaman.

Kendalikan konteks yang hilang atau tidak dapat disahkan sebagai tidak mencukupi. Gunakan ralat yang berbeza untuk token tamat tempoh, pengeluar tidak dipercayai, khalayak salah dan skop hilang; jangan menyamarkan setiap kegagalan sebagai step-up.

3. Benarkan klien mendapatkan kebenaran semula

Klien menghuraikan cabaran dan mengikat sasaran asal, acr_values yang diperlukan, sumber dan PKCE kepada permintaan kebenaran baharu. Klien web menggunakan state dan klien OIDC menggunakan nonce; klien mudah alih tidak seharusnya menganggap cabaran yang belum disahkan sebagai URL kebenaran yang boleh dilaksanakan.

Kebenaran semula masih memerlukan pengesahan dan persetujuan pelayan kebenaran. prompt, max_age atau dasar pengesahan hanyalah satu permintaan; pelayan menulis acr yang dicapai ke dalam token berdasarkan pengesahan sebenar. Klien tidak boleh menandakan token telah dinaik taraf secara setempat.

4. Sahkan token baharu dan niat asal

Sahkan tandatangan, pengeluar, khalayak, skop, exp, iat, acr dan amr yang diperlukan pada token baharu. Dengan introspeksi, wajibkan respons pelayan kebenaran yang dipercayai dengan konteks yang mencukupi. Skop sahaja tidak mencukupi kerana kebenaran dan kekuatan pengesahan adalah dimensi yang berasingan.

Ikat nonce cabaran, ringkasan transaksi (transaction digest) atau ID permintaan kebenaran kepada keadaan pelayan untuk tindakan berisiko tinggi supaya token pengesahan yang lebih tinggi tidak boleh dipindahkan ke transaksi lain. Pastikan khalayak token tepat untuk API sasaran.

5. Cegah gelung, ulangan (replay) dan penurunan taraf

Berikan setiap cabaran TTL yang pendek dan ID unik, dengan merekodkan ringkasan permintaan, penyewa, sumber, tahap yang diperlukan dan bilangan percubaan semula. Benarkan satu atau bilangan percubaan semula yang terhad; lupuskan cabaran yang berjaya dan tamatkan cabaran yang gagal atau tamat tempoh.

Tolak acr_values yang lebih rendah, penggantian sumber atau khalayak, dan pengunduran (fallback) kepada token biasa selepas masa tamat step-up. Gunakan kunci keidempotenan untuk pemindahan supaya percubaan semula pengesahan tidak menduplikasi kesan sampingan.

6. Kendalikan ketersediaan dan sempadan ralat

Jika perkhidmatan kebenaran atau introspeksi tidak tersedia, operasi baca berisiko rendah boleh menggunakan cache pendek; operasi tulis, pembayaran dan perubahan kebenaran akan fail closed secara lalai. Ralat cabaran tidak boleh mendedahkan kaedah pengesahan atau status akaun. Log menyimpan ID cabaran, pengeluar, hasil dan kependaman (latency).

Jejak kadar konteks tidak mencukupi, penyiapan cabaran, gelung, tamat tempoh, ulangan, kegagalan PKCE, penolakan oleh acr dan kesan perniagaan pendua. Bahagikan amaran mengikut sumber dan penyewa untuk memisahkan ralat dasar daripada serangan.

7. Lancarkan dan undurkan (rollback) dengan selamat

Dayakan step-up pada satu API dan penyewa terlebih dahulu, membandingkan respons 401, penyiapan, kependaman, maklum balas sokongan dan penolakan berisiko tinggi. Klien yang tidak memahami cabaran menerima ralat yang didokumenkan dan panduan SDK; token biasa tidak diterima secara senyap untuk semua.

Rollback hanya menyahdayakan dasar sumber yang belum didayakan serta mengekalkan keadaan cabaran dan audit untuk transaksi aktif. Jika konteks bocor, kesan sampingan berulang atau gelung muncul, jeda pelancaran, batalkan dasar dan semak semula pengikatan token.

Contoh jawapan

Saya akan mentakrifkan tahap pengesahan minimum bagi setiap operasi. Selepas mengesahkan token, pelayan sumber mengembalikan 401 dengan insufficient_user_authentication serta acr_values, sumber dan URI ralat yang minimum apabila skop mencukupi tetapi acr atau amr tidak mencukupi. Klien mengekalkan niat dan menggunakan state, nonce serta PKCE untuk kebenaran semula; pelayan kebenaran mengeluarkan token yang konteksnya mencerminkan pengesahan sebenar.

Pelayan sumber mengesahkan semula pengeluar, khalayak, skop, masa, acr dan amr yang diperlukan, mengikat ID cabaran atau ringkasan transaksi kepada keadaan pelayan. Cabaran berjangka hayat pendek, sekali guna dan dihadkan percubaan semula; tahap lebih rendah, khalayak baharu dan pengunduran tanpa syarat ditolak. Operasi tulis berisiko tinggi fail closed semasa gangguan pengesahan, dan pemindahan menggunakan kunci keidempotenan.

Kesilapan lazim

Mengembalikan ralat umum 403 atau 401 dan bukannya cabaran insufficient_user_authentication yang boleh diambil tindakan.
Menyemak skop tetapi tidak menyemak pengeluar, khalayak, acr, amr dan tuntutan masa.
Membiarkan klien menegaskan sendiri acr yang lebih tinggi, atau menurunkannya selepas cabaran.
Menganggap cabaran sebagai URL kebenaran yang tidak disahkan dan melangkau state, nonce atau PKCE.
Mencuba semula tanpa henti atau meninggalkan pengikatan transaksi, membolehkan penggunaan semula token merentasi operasi.
Menurunkan taraf pemindahan atau perubahan kebenaran secara senyap apabila pengesahan tidak tersedia.
Merekodkan akaun, skor risiko atau token lengkap dalam log.

Soalan susulan dan jawapan

Mengapa mengembalikan 401 apabila skop mencukupi tetapi acr tidak?

Skop menyatakan perkara yang boleh diakses oleh token; acr menyatakan cara pengguna disahkan. Sesuatu sumber boleh memerlukan kedua-duanya, jadi klien memerlukan langkah kebenaran baharu.

Apakah yang terkandung dalam sesuatu cabaran?

Hanya tahap pengesahan yang diperlukan, pengecam sumber, URI ralat dan pengecam cabaran berjangka hayat pendek yang diperlukan untuk tindakan klien. Simpan butiran akaun, amaun, risiko dalaman dan kaedah pada bahagian pelayan.

Bolehkah klien memanggil titik akhir token secara terus untuk menaik taraf?

Tidak. Ia mesti mengikut cabaran melalui pengesahan dan persetujuan pelayan kebenaran. Pelayan, bukan klien, yang menegaskan acr yang dicapai dalam token.

Bagaimanakah anda menghalang token yang dinaik taraf daripada digunakan untuk pemindahan lain?

Ikat khalayak, sumber, ID cabaran atau ringkasan transaksi kepada keadaan pelayan sekali guna, dan gunakan kunci keidempotenan untuk pemindahan.

Bagaimana jika introspeksi tidak tersedia buat sementara waktu?

Kelaskan mengikut risiko sumber. Bukti cache pendek boleh melayani operasi baca biasa; pembayaran dan perubahan kebenaran fail closed apabila konteks tidak dapat disahkan.

Bagaimanakah anda menyokong klien lama yang tidak memahami cabaran?

Terbitkan ralat yang didokumenkan dan panduan penghijrahan SDK, kemudian dayakan mengikut penyewa. Operasi berisiko tinggi mengekalkan keperluannya sehingga penghijrahan selesai.