Wawancara umum: Bagaimana Anda memilih FAL1, FAL2, atau FAL3 untuk identitas terfederasi?

Perintah dan konteks

Sebuah relying party (RP) mengintegrasikan beberapa identity provider (IdP) untuk konten publik, administrasi karyawan, dan transaksi bernilai tinggi. Tim memperlakukan FAL sebagai "kekuatan login" tanpa mendefinisikan injeksi asersi, pengikatan pemegang (holder binding), privasi, atau pemulihan. Gunakan NIST SP 800-63C untuk memilih Federation Assurance Level dan jelaskan validasi OIDC serta operasionalnya.

FAL mendeskripsikan bagaimana transaksi federasi melindungi dan mengikat sebuah asersi. Ini tidak menggantikan IAL (pembuktian identitas) atau AAL (kekuatan autentikator). NIST menyatakan bahwa level yang lebih tinggi mencakup persyaratan level yang lebih rendah; FAL3 selain itu mewajibkan pelanggan (subscriber) untuk menunjukkan bukti autentikator terikat secara langsung kepada RP.

Hal yang diuji oleh pewawancara

Pemisahan antara pembuktian identitas, autentikasi pengguna, dan pengiriman asersi.
Karakteristik keamanan yang tepat dan batasan dari FAL1, FAL2, dan FAL3.
Validasi penerbit (issuer), audiens, tanda tangan, nonce, masa berlaku, dan sumber asersi.
Penanganan multi-IdP, injeksi, pengikatan pemegang, privasi, dan pemulihan.
Mengubah keputusan level menjadi kebijakan, pemantauan, migrasi, dan pengecualian.

Pertanyaan klarifikasi

Apakah sumber daya tersebut merupakan konten publik, konsol karyawan, atau transaksi bernilai tinggi?
Apakah federasi menggunakan OIDC, SAML, atau protokol lain, dan siapa yang menerbitkan serta memvalidasi asersi?
Haruskah desain kebal terhadap injeksi asersi, transfer token, atau replay setelah pencurian? Bisakah pengguna menyajikan autentikator terikat?
Bagaimana mekanisme pergantian perangkat, pemulihan, penggunaan offline, dan perangkat bersama?
Bagaimana pemetaan penerbit, audiens, JWKS, dan tenant dikelola di seluruh IdP?

Jawaban 30 detik

Pilih FAL berdasarkan risiko sumber daya, bukan dari layar login. FAL1 mencakup pengiriman asersi dasar; FAL2 menambahkan perlindungan terhadap serangan federasi seperti injeksi asersi; FAL3 selain itu memerlukan bukti autentikator yang terikat pada pelanggan yang disajikan langsung ke RP. Lacak IAL, AAL, dan FAL secara terpisah. Validasi issuer, audiens, tanda tangan, nonce, dan waktu pada OIDC. Cadangkan FAL3 untuk operasi bernilai tinggi dan rencanakan pemulihan, privasi, rotasi kunci, serta biaya peluncuran.

Jawaban mendalam

1. Pisahkan IAL, AAL, dan FAL

IAL mendeskripsikan pembuktian identitas, AAL mendeskripsikan bagaimana pengguna membuktikan kontrol atas autentikator, dan FAL mendeskripsikan perlindungan asersi IdP yang dikirimkan ke RP. Pengguna mungkin memiliki AAL yang kuat sementara transaksi federasi memiliki FAL yang tidak memadai; FAL2 tidak membuktikan tingkat pembuktian identitas.

Untuk setiap sumber daya, catat ketiga level, IdP yang diizinkan, jenis asersi, jalur pemulihan, dan retensi audit. Jangan memetakan "menggunakan OIDC" secara langsung ke suatu FAL.

2. Pahami ketiga level FAL

FAL1 menyediakan pengiriman asersi federasi dasar untuk layanan berisiko lebih rendah, namun tetap memerlukan validasi tanda tangan, penerbit, audiens, masa berlaku, dan sesi.

FAL2 menambahkan perlindungan pengiriman asersi yang lebih kuat terhadap penyerang yang menyuntikkan asersi valid ke dalam transaksi federasi lain. RP memerlukan konteks transaksi yang eksplisit, IdP tepercaya, dan pemeriksaan injeksi.

FAL3 dibangun di atas FAL2 dan memerlukan bukti autentikator terikat yang disajikan langsung oleh pelanggan, membuat transfer asersi menjadi lebih sulit. Ini menambah biaya pengikatan perangkat, pemulihan, ketersediaan, dan privasi, sehingga tidak boleh dijadikan default untuk setiap login.

3. Validasi asersi OIDC

Validasi tanda tangan ID Token, iss, aud, exp, iat, dan nonce. OpenID Connect mewajibkan perbandingan nonce dengan nilai yang dikirimkan dalam permintaan autentikasi; komponen jalur (path) dari URL penerbit adalah bagian dari identitasnya.

Ambil JWKS hanya dari penerbit yang disetujui dan segarkan secara terkontrol saat kid tidak ditemukan. Jangan membangun URL penemuan dari input pengguna atau memperlakukan klaim email sebagai kunci identitas lintas tenant.

4. Menahan injeksi dan transfer asersi

Simpan permintaan otorisasi, issuer, ID klien, URI pengalihan, state, dan nonce di sisi server. Callback harus cocok dengan transaksi asli; issuer yang tidak dikenal, audiens yang salah, state yang berulang, atau nonce yang salah akan menghentikan alur.

Sumber daya berisiko tinggi juga mengikat transaksi, sumber daya, dan sesi. FAL2 mengatasi masalah inti injeksi asersi federasi tetapi tidak menggantikan PKCE, identifikasi issuer, audiens token, atau otorisasi sumber daya.

5. Rancang autentikator terikat FAL3

FAL3 mewajibkan pelanggan untuk menunjukkan bukti autentikator terikat secara langsung kepada RP. RP mendaftarkan pengikatan tersebut, memeriksa kesegaran bukti dan status perangkat, serta menangani kehilangan, penggantian, pencabutan, dan pemulihan.

Pemulihan tidak boleh hanya bergantung pada login IdP biasa, atau hal itu dapat melewati pengikatan. Pemulihan berisiko tinggi mungkin memerlukan faktor independen, tinjauan manual, atau aktivasi yang tertunda; tim produk dan dukungan harus menerima biaya dan tingkat kegagalan yang lebih tinggi.

6. Beroperasi dengan privasi dan multi-IdP

Minta hanya klaim yang diperlukan untuk bisnis dan batasi retensi asersi serta bidang log. Subjek dari IdP yang berbeda tidak boleh digabungkan ke dalam satu identitas lintas domain tanpa pemetaan berlingkup issuer dan tenant.

Pantau kegagalan tanda tangan, konflik issuer, replay nonce, penyegaran JWKS, ukuran asersi, peristiwa pemulihan, dan keberhasilan berdasarkan FAL. Gunakan overlap selama rotasi kunci dan pertahankan konfigurasi issuer lama tetap dapat diverifikasi selama TTL sesi yang sedang berjalan.

7. Memilih, meluncurkan, dan menangani pengecualian

Konten publik biasanya tidak memerlukan FAL yang tinggi; konsol karyawan dapat menggunakan FAL2; transfer, kunci administrator, dan tindakan yang tidak dapat dibatalkan memerlukan penilaian FAL3. Pengecualian harus mencatat sumber daya, tenggat waktu, kontrol kompensasi, dan pemilik.

Luncurkan berdasarkan tenant dan sumber daya sambil membandingkan penyelesaian, pemulihan, tiket dukungan, dan peristiwa keamanan. Hentikan peluncuran jika terjadi injeksi asersi atau kegagalan pengikatan; jangan secara diam-diam menurunkan operasi berisiko tinggi ke FAL1 demi ketersediaan.

Contoh jawaban

Saya akan mengevaluasi IAL, AAL, dan FAL secara terpisah. Gunakan FAL1 untuk konten berisiko rendah, FAL2 untuk alur karyawan dan multi-IdP dengan pertahanan injeksi yang lebih kuat, dan pertimbangkan FAL3 untuk operasi bernilai tinggi seperti kunci administrator atau transfer yang tidak dapat dibatalkan, dengan autentikator terikat dan pemulihan yang dirancang sejak awal.

Setiap callback OIDC memvalidasi issuer, audiens, tanda tangan, waktu, dan nonce, yang mengikat issuer, klien, state, URI pengalihan, dan transaksi. JWKS hanya berasal dari issuer yang disetujui dan dirotasi dengan overlap. Luncurkan per tenant, pantau injeksi, replay, pemulihan, dan penyelesaian, serta berikan tenggat waktu dan kontrol kompensasi untuk setiap pengecualian. Alur berisiko tinggi harus fail-closed selama terjadi pemadaman verifikasi.

Kesalahan umum

Memperlakukan FAL sebagai kekuatan login dan mengabaikan IAL serta AAL.
Mengasumsikan bahwa OIDC secara otomatis berarti FAL2 atau FAL3.
Hanya memeriksa tanda tangan, bukan issuer, audiens, nonce, masa berlaku, dan konteks transaksi.
Membiarkan issuer atau kid yang diberikan pengguna memicu penemuan arbitrer atau pengambilan kunci.
Mengklaim FAL3 adalah satu pengaturan tunggal tanpa desain autentikator terikat dan pemulihan.
Menggabungkan klaim email dari IdP yang berbeda menjadi satu identitas.
Menurunkan operasi berisiko tinggi secara diam-diam ke FAL1 demi tingkat penyelesaian.

Pertanyaan lanjutan dan jawaban

Apa perbedaan FAL2 dengan AAL2?

AAL2 mendeskripsikan kekuatan autentikator; FAL2 mendeskripsikan perlindungan pengiriman asersi federasi. Keduanya independen dan harus dicatat serta disusun secara terpisah.

Kapan FAL3 sebanding dengan biayanya?

Untuk tindakan bernilai tinggi di mana risiko transfer asersi sangat penting dan pengguna dapat menyajikan bukti autentikator terikat, seperti kunci administrator atau transaksi yang tidak dapat dibatalkan. Biaya dan kapasitas pemulihan harus dinilai secara bersamaan.

Mengapa nonce masih penting?

Nonce mengikat ID Token ke permintaan autentikasi ini dan mengurangi replay dari respons lama. Ini tidak menggantikan issuer, audiens, tanda tangan, atau kebijakan FAL.

Bagaimana jika JWKS IdP tidak tersedia?

Gunakan cache pendek yang terkontrol. Jika asersi berisiko tinggi tidak dapat diverifikasi, lakukan fail-closed dan berikan peringatan; jangan pernah menerima kunci yang tidak dikenal atau melewati verifikasi.

Bagaimana Anda menangani penggantian perangkat?

FAL3 memerlukan pengikatan baru dan jalur pemulihan yang disetujui. Login IdP biasa dapat menjadi salah satu faktor pemulihan tetapi tidak dapat secara diam-diam mewarisi pengikatan perangkat lama.

Bagaimana Anda menjelaskan pilihan FAL kepada tim produk?

Jelaskan risiko sumber daya, konsekuensi transfer asersi, populasi pengguna, biaya pemulihan, dan persyaratan kepatuhan. Catat tenggat waktu, metrik, dan kontrol kompensasi daripada hanya menyebutkan nama level saja.