Prompt dan konteks
Anda memiliki titik masuk log masuk perusahaan untuk laman web berbilang bahasa. Pihak produk mahu pelayar menawarkan akaun penyedia identiti hanya selepas pengguna membuat pilihan yang jelas, manakala keperluan privasi melarang kebergantungan pada kuki pihak ketiga untuk penjejakan. Reka bentuk kerjasama antara pihak yang bergantung (RP), penyedia identiti (IdP), dan pelayan, termasuk pelayar yang tidak disokong, penolakan pengguna, pelbagai IdP, penciptaan sesi, dan log keluar.
Perkara yang diuji oleh penemu duga
Jawapan yang kukuh menganggap FedCM sebagai antara muka persekutuan identiti berperantaraan pelayar, bukan sebagai pengganti kepada pengesahan token. RP meminta identiti dengan navigator.credentials.get(), pelayar memaparkan pilihan akaun, dan IdP mengembalikan penegasan (assertion) jangka pendek atau hasil kebenaran. Pelayan masih mengesahkan tandatangan, issuer, audience, nonce, dan state sebelum mencipta sesi tempatan. Jawapan tersebut juga perlu membezakan had kuki pihak ketiga, dasar kebenaran (permission policy), pilihan pengguna, dan sandaran pengalihan OAuth/OIDC tradisional.
Soalan penjelasan untuk ditanya terlebih dahulu
Protokol dan model kepercayaan
Sahkan sama ada IdP menggunakan OAuth, OIDC, atau assertion tersuai, sama ada pelbagai IdP dibenarkan, dan bagaimana pelayan mengurus konfigurasi JWKS, issuer, dan audience. FedCM tidak menggantikan giliran kunci (key rotation) atau pengesahan token di sempadan IdP.
Keperluan pelayar dan privasi
Sahkan pelayar sasaran, iframe terbenam, dasar perusahaan, dan pendirian kuki pihak ketiga semasa. Sokongan dan kelakuan UI FedCM bergantung pada pelayar; kelakuan Chrome tidak boleh diandaikan di semua tempat.
Pautan akaun dan dasar log keluar
Sahkan sama ada satu subject luaran boleh dipetakan kepada satu akaun tempatan, bagaimana alamat e-mel pendua dikendalikan, sama ada log keluar global mesti memberitahu IdP, dan sama ada permintaan yang ditolak boleh berundur (fallback) kepada log masuk kata laluan atau e-mel.
Rangka kerja jawapan 30 saat
"Saya menganggap FedCM sebagai lapisan pilihan identiti yang dikawal oleh pelayar. RP memperoleh state sekali guna daripada pelayannya, kemudian memanggil navigator.credentials.get(). Pelayar memaparkan pemilih akaun IdP, dan IdP mengembalikan hasil identiti yang terikat dengan protokol. Pelayan mengesahkan issuer, tandatangan, audience, nonce, state, dan pemetaan akaun sebelum mencipta sesi laman web. Pelayar yang tidak disokong, sekatan kebenaran, pembatalan, dan penolakan pelayan adalah keadaan yang berbeza. Sandarannya ialah OAuth/OIDC dengan perlindungan CSRF dan PKCE. Log keluar mesti membezakan sesi laman web daripada sesi IdP; mengosongkan satu kuki bukan log keluar global."
Jawapan mendalam langkah demi langkah
Langkah 1: Konfigurasikan RP dan IdP
Pelayan menyimpan issuer, ID klien, endpoint JWKS, protokol yang dibenarkan, dan dasar callback untuk setiap IdP yang dipercayai. Frontend hanya menerima pengecam konfigurasi yang diluluskan pelayan dan tidak sekali-kali menerima URL IdP sewenang-wenangnya daripada pengguna. Untuk pelaksanaan berbilang penyewa (multi-tenant), ikat senarai dibenarkan (allowlist) pada setiap penyewa untuk mengelakkan open redirect atau penghantaran token merentas penyewa.
Langkah 2: Cipta keadaan log masuk sekali guna
Selepas pengguna memulakan log masuk, pelayan RP mencipta state yang tidak dapat diramalkan, nonce, dan rekod aliran jangka pendek yang terikat pada sesi pelayar, penyewa, dan laluan kembali. Frontend menghantar parameter yang disediakan pelayan kepada FedCM. State dan nonce kekal sebagai nilai sekali guna milik pelayan; frontend tidak boleh menjana atau menggunakannya semula.
Langkah 3: Buat permintaan berperantaraan pelayar
Frontend memanggil navigator.credentials.get() dalam konteks selamat dan di bawah dasar kebenaran yang diperlukan. Pelayar memaparkan pemilih akaun dan hanya meneruskan selepas pemilihan pengguna yang eksplisit. Permintaan FedCM membawa destinasi fetch khas supaya pelayan dapat mengenal pasti aliran identiti; frontend tidak boleh menganggap kemunculan UI sebagai kejayaan pengesahan.
Langkah 4: Sahkan hasil identiti pada pelayan
Pelayan menyemak issuer, tandatangan, tarikh luput, audience, nonce, state, dan subject, kemudian memetakan identiti luaran menggunakan dasar yang jelas. E-mel ialah atribut tambahan, bukan kunci penggabungan akaun automatik. Hanya selepas pengesahan, pelayan mengeluarkan sesi laman web dan merekodkan IdP, subject, masa pengesahan, dan isyarat risiko yang berkaitan.
Langkah 5: Reka bentuk sandaran (fallback) dan keadaan kegagalan
Pelayar yang tidak disokong, sekatan kebenaran, pembatalan pengguna, dan kegagalan rangkaian memerlukan pengendalian berasingan. Sandaran pengalihan OAuth/OIDC menggunakan PKCE, URI pengalihan yang tepat, state, dan nonce; ia kembali melalui lapisan pemetaan akaun sisi pelayan yang sama. UI menerangkan tindakan seterusnya tanpa mendedahkan issuer, token, atau ralat pengesahan dalaman.
Langkah 6: Kendalikan pelbagai IdP dan pemautan akaun
Apabila beberapa IdP dibenarkan, halaman tersebut memaparkan senarai yang diluluskan perniagaan dan pelayar serta IdP melengkapkan pemilihan akaun. Pelayan menggunakan (issuer, subject) sebagai kunci luaran yang stabil dan tidak sekali-kali menggabungkan akaun secara senyap melalui e-mel sahaja. Menambah IdP memerlukan sesi yang disahkan atau pengesahan bertingkat (step-up) dan menghasilkan peristiwa pautan atau nyahpautan yang boleh diaudit.
Langkah 7: Log keluar, pembatalan, dan pelancaran berperingkat
Log keluar laman web membatalkan sesi tempatan, mengosongkan kuki selamat, dan membatalkan token penyegaran (refresh tokens); jika protokol dan IdP menyokongnya, klien juga boleh menggunakan log keluar IdP. FedCM mungkin tidak meliputi setiap keupayaan log keluar yang bergantung pada kuki, jadi jelaskan perbezaan antara mendaftar keluar dari laman web dan mendaftar keluar dari penyedia identiti. Lancarkan secara berperingkat mengikut keupayaan pelayar dan kadar ralat dengan suis sandaran yang boleh diperhatikan.
Contoh jawapan berkualiti tinggi
Saya akan memisahkan pilihan identiti pelayar, bukti IdP, dan penciptaan sesi RP. Pelayan RP mencipta state jangka pendek, nonce, dan data aliran terikat penyewa. Frontend memulakan FedCM dalam konteks selamat; pelayar menunjukkan pemilih akaun, dan IdP mengembalikan hasil selepas pengesahan pengguna. Pelayan mengesahkan tandatangan JWKS issuer, audience, nonce, state, tarikh luput, dan subject, kemudian memetakan (issuer, subject) kepada akaun tempatan sebelum mencipta sesi laman web.
Pelayar yang tidak disokong, sekatan dasar, pembatalan, dan kegagalan rangkaian kekal sebagai keadaan berasingan dan berundur (fallback) kepada OAuth/OIDC dengan PKCE. Sandaran mengekalkan pengesahan pelayan dan dasar pemautan yang sama. Pelbagai IdP hanya datang daripada allowlist pelayan, dan e-mel bukan kunci penggabungan automatik. Log keluar membatalkan sesi laman web; log keluar penyedia ialah keupayaan berasingan yang dijelaskan kepada pengguna. Semasa pelancaran, saya akan memantau kejayaan, pembatalan, sandaran, dan konflik pautan akaun mengikut pelayar dan IdP, dengan suis yang melumpuhkan hanya titik masuk FedCM jika ralat meningkat.
Kesilapan biasa
- Kesilapan: Menganggap hasil FedCM sebagai sesi yang telah disahkan. → Sebab ia gagal: Pilihan berperantaraan pelayar tidak mengesahkan issuer, tandatangan, atau nonce. → Penyelesaian: Hantar setiap hasil melalui satu laluan pengesahan pelayan dan penciptaan sesi.
- Kesilapan: Memadankan akaun sedia ada hanya melalui e-mel. → Sebab ia gagal: E-mel mungkin tidak disahkan, dikitar semula, atau bertindih merentas IdP. → Penyelesaian: Gunakan
(issuer, subject)sebagai kunci luaran dan perlukan pengesahan eksplisit untuk pemautan berasaskan e-mel. - Kesilapan: Menyimpan token dalam storan frontend selepas FedCM gagal. → Sebab ia gagal: Ia meluaskan pendedahan XSS dan memintas dasar sesi sedia ada. → Penyelesaian: Biarkan pelayan menukar hasil dan menetapkan kuki sesi yang dilindungi; frontend hanya mengendalikan status.
- Kesilapan: Mengandaikan log keluar laman web turut melog keluar pengguna daripada IdP. → Sebab ia gagal: Sesi-sesi tersebut mempunyai kitaran hayat dan keupayaan protokol yang berbeza. → Penyelesaian: Batalkan setiap sesi secara berasingan dan maklumkan skop log keluar.
Soalan susulan dan jawapan
Soalan susulan 1: Bagaimanakah FedCM berkaitan dengan pengalihan OAuth biasa?
FedCM mengubah cara pelayar mengantarakan pilihan akaun dan interaksi silang tapak; OAuth/OIDC masih menyediakan kebenaran dan bukti identiti. Kedua-duanya boleh berkongsi issuer, nonce, state, PKCE, dan pemetaan akaun sisi pelayan. Sandaran tidak boleh membuang semakan tersebut.
Soalan susulan 2: Mengapakah sekatan kuki pihak ketiga menjejaskan persekutuan?
IdP terbenam sebelum ini mungkin telah menggunakan kuki pihak ketiga untuk mengecam pengguna yang telah log masuk. Kuki yang dipisahkan (partitioned) atau disekat memerlukan pilihan yang eksplisit dan boleh dilihat pengguna. FedCM mengurangkan pengecaman silang tapak secara tersirat tetapi tidak menentukan kebenaran aplikasi.
Soalan susulan 3: Bolehkah IdP yang ditolak digantikan secara senyap dengan yang lain?
Jangan anggap penolakan sebagai persetujuan tersirat. Tawarkan IdP lain yang diluluskan atau entri kata laluan sebagai tindakan pengguna yang eksplisit, dan cipta state, nonce, dan data aliran baharu untuk penyedia yang dipilih dan bukannya menggunakan semula permintaan yang telah selesai.
Soalan susulan 4: Bagaimanakah anda membuktikan pelancaran berperingkat tidak menjejaskan log masuk?
Segmenkan metrik kejayaan, pembatalan, sekatan dasar, sandaran, konflik akaun, dan masa penyiapan mengikut pelayar, IdP, wilayah, dan konteks pembenaman. Beri amaran tentang anomali issuer, kegagalan tandatangan, dan main semula nonce (nonce replay). Kekalkan suis pelayan yang melumpuhkan FedCM sahaja sambil mengekalkan laluan pengesahan OAuth yang sedia ada.