Konteks dan prompt
Anda bertanggung jawab atas titik masuk sign-in tingkat enterprise untuk situs multibahasa. Tim produk menginginkan peramban hanya menawarkan akun penyedia identitas setelah pengguna membuat pilihan yang jelas, sementara persyaratan privasi melarang ketergantungan pada cookie pihak ketiga untuk pelacakan. Rancang kolaborasi antara relying party (RP), identity provider (IdP), dan server, termasuk penanganan peramban yang tidak didukung, penolakan pengguna, penggunaan beberapa IdP, pembuatan sesi, dan proses sign-out.
Hal yang diuji oleh pewawancara
Jawaban yang kuat memperlakukan FedCM sebagai antarmuka federasi identitas yang dimediasi peramban, bukan sebagai pengganti validasi token. RP meminta identitas dengan navigator.credentials.get(), peramban menampilkan pilihan akun, dan IdP mengembalikan asersi atau hasil otorisasi berumur pendek. Server tetap memvalidasi tanda tangan, issuer, audience, nonce, dan state sebelum membuat sesi lokal. Jawaban juga harus memisahkan batasan cookie pihak ketiga, kebijakan izin (permission policy), pilihan pengguna, dan fallback pengalihan OAuth/OIDC tradisional.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Protokol dan model kepercayaan
Konfirmasikan apakah IdP menggunakan OAuth, OIDC, atau asersi kustom, apakah beberapa IdP diizinkan, dan bagaimana server mengelola konfigurasi JWKS, issuer, dan audience. FedCM tidak menggantikan rotasi kunci atau validasi token pada batas IdP.
Persyaratan peramban dan privasi
Konfirmasikan peramban target, iframe yang disematkan, kebijakan enterprise, dan postur cookie pihak ketiga saat ini. Dukungan FedCM dan perilaku antarmuka pengguna bergantung pada peramban; perilaku Chrome tidak dapat diasumsikan berlaku di mana-mana.
Kebijakan penautan akun dan logout
Konfirmasikan apakah satu subject eksternal dapat dipetakan ke satu akun lokal, bagaimana penanganan alamat email duplikat, apakah logout global harus memberi tahu IdP, dan apakah permintaan yang ditolak dapat beralih (fallback) ke sign-in dengan kata sandi atau email.
Kerangka jawaban 30 detik
“Saya memperlakukan FedCM sebagai lapisan pemilihan identitas yang dikendalikan oleh peramban. RP memperoleh state sekali pakai dari servernya, kemudian memanggil navigator.credentials.get(). Peramban menampilkan pemilih akun IdP, dan IdP mengembalikan hasil identitas yang terikat protokol. Server memvalidasi issuer, tanda tangan, audience, nonce, state, dan pemetaan akun sebelum membuat sesi situs. Peramban yang tidak didukung, pemblokiran izin, pembatalan, dan penolakan server adalah state yang berbeda. Fallback-nya adalah OAuth/OIDC dengan perlindungan CSRF dan PKCE. Sign-out harus membedakan sesi situs dari sesi IdP; menghapus satu cookie bukan berarti logout global.”
Jawaban mendalam langkah demi langkah
Langkah 1: Mengonfigurasi RP dan IdP
Server menyimpan issuer, client ID, endpoint JWKS, protokol yang diizinkan, dan kebijakan callback untuk setiap IdP tepercaya. Frontend hanya menerima pengidentifikasi konfigurasi yang disetujui server dan tidak pernah menerima URL IdP sembarangan dari pengguna. Untuk penerapan multi-tenant, tautkan allowlist ke setiap penyewa guna mencegah open redirect atau pengiriman token lintas-tenant.
Langkah 2: Membuat state login sekali pakai
Setelah pengguna memulai sign-in, server RP membuat state yang tidak dapat diprediksi, nonce, dan catatan alur berumur pendek yang terikat pada sesi peramban, tenant, serta jalur kembali (return path). Frontend mengirimkan parameter yang disediakan server ke FedCM. State dan nonce tetap menjadi nilai sekali pakai milik server; frontend tidak boleh membuat atau menggunakannya kembali.
Langkah 3: Melakukan permintaan yang dimediasi peramban
Frontend memanggil navigator.credentials.get() dalam konteks yang aman dan di bawah permission policy yang diperlukan. Peramban menampilkan pemilih akun dan melanjutkan proses hanya setelah adanya pemilihan eksplisit dari pengguna. Permintaan FedCM membawa fetch destination khusus agar server dapat mengidentifikasi alur identitas; frontend tidak boleh menganggap kemunculan UI sebagai keberhasilan autentikasi.
Langkah 4: Memvalidasi hasil identitas di server
Server memeriksa issuer, tanda tangan, kedaluwarsa, audience, nonce, state, dan subject, lalu memetakan identitas eksternal menggunakan kebijakan yang eksplisit. Email adalah atribut tambahan, bukan kunci penggabungan akun otomatis. Hanya setelah validasi, server menerbitkan sesi situs dan mencatat IdP, subject, waktu autentikasi, serta sinyal risiko yang relevan.
Langkah 5: Merancang alur fallback dan state kegagalan
Peramban yang tidak didukung, pemblokiran izin, pembatalan pengguna, dan kegagalan jaringan memerlukan penanganan terpisah. Fallback pengalihan OAuth/OIDC menggunakan PKCE, URI pengalihan yang tepat, state, dan nonce; proses ini kembali melalui lapisan pemetaan akun sisi server yang sama. UI menjelaskan tindakan selanjutnya tanpa mengekspos issuer, token, atau kesalahan validasi internal.
Langkah 6: Menangani beberapa IdP dan penautan akun
Ketika beberapa IdP diizinkan, halaman menampilkan daftar yang disetujui bisnis, dan peramban serta IdP menyelesaikan pemilihan akun. Server menggunakan (issuer, subject) sebagai kunci eksternal yang stabil dan tidak pernah menggabungkan akun secara diam-diam hanya berdasarkan email. Menambahkan IdP memerlukan sesi terautentikasi atau verifikasi bertahap (step-up) dan menghasilkan event penautan atau pemutusan tautan yang dapat diaudit.
Langkah 7: Logout, pencabutan, dan peluncuran bertahap
Logout situs mencabut sesi lokal, menghapus cookie aman, dan membatalkan refresh token; jika protokol dan IdP mendukungnya, klien juga dapat memanggil logout IdP. FedCM mungkin tidak mencakup semua kapabilitas logout yang bergantung pada cookie, jadi jelaskan perbedaan antara keluar dari situs dan keluar dari penyedia identitas. Luncurkan secara bertahap berdasarkan kapabilitas peramban dan tingkat kesalahan dengan switch fallback yang dapat dipantau.
Contoh jawaban berkualitas tinggi
Saya akan memisahkan pilihan identitas peramban, bukti IdP, dan pembuatan sesi RP. Server RP membuat state berumur pendek, nonce, dan data alur yang terikat dengan tenant. Frontend memulai FedCM dalam konteks aman; peramban menampilkan pemilih akun, dan IdP mengembalikan hasil setelah konfirmasi pengguna. Server memvalidasi tanda tangan JWKS issuer, audience, nonce, state, kedaluwarsa, dan subject, kemudian memetakan (issuer, subject) ke akun lokal sebelum membuat sesi situs.
Peramban yang tidak didukung, pemblokiran kebijakan, pembatalan, dan kegagalan jaringan tetap menjadi state terpisah dan dialihkan kembali ke OAuth/OIDC dengan PKCE. Fallback mempertahankan kebijakan validasi dan penautan server yang sama. Penggunaan beberapa IdP hanya berasal dari allowlist server, dan email bukan kunci penggabungan otomatis. Logout mencabut sesi situs; logout penyedia adalah kapabilitas terpisah yang dijelaskan kepada pengguna. Selama peluncuran, saya akan memantau keberhasilan, pembatalan, fallback, dan konflik penautan akun berdasarkan peramban dan IdP, dengan tombol switch yang hanya menonaktifkan titik masuk FedCM jika tingkat kesalahan meningkat.
Kesalahan umum
- Kesalahan: Memperlakukan hasil FedCM sebagai sesi yang sudah terautentikasi. → Mengapa gagal: Pilihan yang dimediasi peramban tidak memvalidasi issuer, tanda tangan, atau nonce. → Solusi: Kirim setiap hasil melalui satu jalur validasi dan pembuatan sesi di server.
- Kesalahan: Mencocokkan akun yang ada hanya berdasarkan email. → Mengapa gagal: Email mungkin belum diverifikasi, didaur ulang, atau duplikat di berbagai IdP. → Solusi: Gunakan
(issuer, subject)sebagai kunci eksternal dan wajibkan konfirmasi eksplisit untuk penautan berbasis email. - Kesalahan: Menyimpan token di penyimpanan frontend setelah FedCM gagal. → Mengapa gagal: Ini memperluas paparan XSS dan melewati kebijakan sesi yang ada. → Solusi: Biarkan server menukar hasilnya dan menetapkan cookie sesi yang dilindungi; frontend hanya menangani status.
- Kesalahan: Mengasumsikan bahwa logout dari situs otomatis mengeluarkan pengguna dari IdP. → Mengapa gagal: Sesi-sesi tersebut memiliki siklus hidup dan kapabilitas protokol yang berbeda. → Solusi: Cabut setiap sesi secara terpisah dan komunikasikan cakupan dari logout tersebut.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Bagaimana hubungan FedCM dengan pengalihan OAuth biasa?
FedCM mengubah cara peramban memediasi pemilihan akun dan interaksi lintas-situs; OAuth/OIDC tetap menyediakan otorisasi dan bukti identitas. Keduanya dapat berbagi issuer, nonce, state, PKCE, dan pemetaan akun sisi server. Fallback tidak boleh menghilangkan pemeriksaan tersebut.
Pertanyaan lanjutan 2: Mengapa pembatasan cookie pihak ketiga memengaruhi federasi?
IdP yang disematkan sebelumnya mungkin menggunakan cookie pihak ketiga untuk mengenali pengguna yang telah masuk. Cookie yang dipartisi atau diblokir memerlukan pilihan eksplisit yang terlihat oleh pengguna sebagai gantinya. FedCM mengurangi pengenalan lintas-situs implisit tetapi tidak menentukan izin aplikasi.
Pertanyaan lanjutan 3: Bisakah IdP yang ditolak diganti secara diam-diam dengan yang lain?
Jangan memperlakukan penolakan sebagai persetujuan implisit. Tawarkan IdP lain yang disetujui atau input kata sandi sebagai tindakan pengguna yang eksplisit, dan buat state, nonce, serta data alur baru untuk penyedia yang dipilih alih-alih menggunakan kembali permintaan yang sudah selesai.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan bahwa peluncuran bertahap tidak mengganggu alur sign-in?
Segmentasikan metrik keberhasilan, pembatalan, pemblokiran kebijakan, fallback, konflik akun, dan waktu penyelesaian berdasarkan peramban, IdP, wilayah, dan konteks penyematan. Berikan peringatan pada anomali issuer, kegagalan tanda tangan, dan replay nonce. Sediakan switch server yang hanya menonaktifkan FedCM sementara membiarkan jalur validasi OAuth yang sudah ada tetap utuh.