Tahun Pertama Passkey B2B: Dari Pengguna kepada Enterprise
Passkey yang didorong bersama oleh Apple, Google, dan Microsoft dari 2022 hingga 2024 pada mulanya tersebar sebagai cara pengesahan untuk pengguna. Walau bagaimanapun, penerapan B2B maju pesat sejak separuh kedua 2025, dan 2026 boleh dianggap sebagai "tahun pertama deployment Passkey B2B". Okta, Entra ID, Google Workspace, dan 1Password Business semuanya menyokong Cross-Device Passkey dan Passkey serentak, dan telah matang kepada reka bentuk yang boleh beroperasi bersama kunci keselamatan FIDO2 (YubiKey 5C, Google Titan).
Sebab utama Passkey diterima pakai sepenuhnya dalam B2B ialah rintangan phishing. Dari 2024 hingga 2025, kit phishing AiTM (Adversary-in-the-Middle) yang menyasarkan syarikat Jepun meningkat pesat. TOTP konvensional dan SMS OTP adalah terdedah kepada serangan yang merampas sesi pengesahan melalui proksi perantara, dan beberapa insiden berlaku di mana ribuan akaun dalam SaaS besar domestik dikompromi dalam satu malam. Passkey (WebAuthn) mempunyai rintangan struktural terhadap AiTM kerana pengikatan domain bermakna tandatangan tidak sah di tapak phishing. Fakta bahawa ia "dijamin oleh protokol" dan bukan "berhati-hati dalam operasi" menjadi asas keputusan pengurusan.
Pertukaran ganti antara Passkey serentak (melalui iCloud Keychain dan Google Password Manager) dan Passkey terikat peranti (terhad kepada YubiKey dan lain-lain) kekal sebagai isu berterusan. Kewangan dan pertahanan lebih suka terikat peranti, manakala Passkey serentak lebih praktikal untuk deployment pekerja yang meluas. Pengiktirafan Passkey serentak sebagai AAL2 dalam semakan 2025 NIST SP 800-63B menjadi angin sokongan untuk penggubalan polisi.
Perangkap Pelaksanaan WebAuthn dan Pemulihan Akaun
Perkara pertama yang menimbulkan masalah ialah reka bentuk RP ID (Relying Party ID). Kerana RP ID adalah mengikut domain, pendaftaran Passkey berasingan diperlukan untuk `corp.example.jp` dan `portal.example.jp`. Jika anda ingin menyatukan, anda perlu menjadikan domain induk `example.jp` sebagai RP ID, tetapi organisasi yang berkongsi domain induk dengan tapak pemasaran perlu menilai impak dengan teliti.
Pemulihan akaun adalah cabaran terbesar dalam operasi Passkey. Jika reka bentuk pemulihan diabaikan, cara sandaran yang lemah (e-mel OTP, SMS OTP) kekal, dan kekuatan keselamatan diturunkan kepada sandaran yang kekal. Cadangan ialah reka bentuk tiga lapisan. Pemulihan ringan (log masuk semula dari peranti lain) diselesaikan secara automatik dengan Passkey serentak, pemulihan sederhana (kehilangan semua peranti) memerlukan kelulusan pentadbir dan pengesahan identiti, dan pemulihan berat (syak manipulasi ID) memerlukan pengesahan identiti luar talian wajib. Penting juga untuk tidak melalui CS untuk pemulihan berat, kerana kejayaan social engineering melalui CS benar-benar berlaku pada 2024.
SCIM dan Automasi Penyediaan
Penyediaan automatik melalui SCIM 2.0 bukan lagi pilihan tetapi prasyarat. Dengan menyegerakkan SCIM dari IdP ke setiap SaaS, penambahan pengguna, kemas kini atribut, dan penyahdayaan merambat secara masa nyata. SaaS utama (Salesforce, Slack, Notion, GitHub Enterprise, Atlassian) menyediakan SCIM 2.0 sebagai standard, dan kualiti pelaksanaan sisi penerima juga telah meningkat dengan ketara berbanding 2024.
Apa yang sering terlepas pandang dalam operasi SCIM ialah reka bentuk pemetaan atribut. Jadual pemetaan jabatan, jawatan, dan kategori pekerjaan sisi IdP kepada kumpulan dan peranan hak akses sisi SaaS perlu dikekalkan dalam bentuk yang boleh diselenggarakan bersama antara HR dan jabatan IT. Okta Workflows dan Entra Lifecycle Workflows mempunyai UI tanpa kod, dengan kaedah ungkapan menggunakan rantaian pernyataan IF sebagai arus perdana. Penukaran atribut bergantung pada skrip menjadi corak tipikal yang tidak dapat mengikut perubahan enam bulan kemudian. Pelan pemisahan dari penyegerakan CSV harian semakin banyak diminta dalam audit dalaman 2026.
Dari SAML kepada OIDC: Mengapa Sekarang
SAML telah lama menjadi standard B2B SSO, tetapi pada 2026, OIDC menjadi pilihan pertama untuk projek baharu. Terdapat tiga sebab. Pertama, sokongan mudah alih/SPA di mana ubah hala XML SAML adalah menyusahkan berbanding OIDC menggunakan PKCE pada mudah alih asli. Kedua, kerumitan tandatangan dan penyulitan di mana spesifikasi XML Signature SAML adalah luas, dan kerentanan akibat perbezaan pelaksanaan (serangan XML Signature Wrapping dan lain-lain) sering berlaku secara historis. Ketiga, kerana pengesahan (ID Token) dan kebenaran API (Access Token) boleh dipisahkan secara struktural, reka bentuk kebenaran dalam persekitaran perkhidmatan mikro menjadi jelas.
Walau bagaimanapun, penghapusan penuh SAML adalah tidak praktikal. SAP SuccessFactors, Workday, dan sebahagian Oracle Cloud hanya mempunyai SAML sebagai SSO. Strategi migrasi ialah "baharu menggunakan OIDC, SAML sedia ada dikekalkan buat masa ini, kumpulkan ke infrastruktur IdP yang menyokong kedua-dua". Perangkap dalam migrasi ialah "perbezaan pemetaan atribut", di mana pertentangan nama kumpulan dan ketidaksepadanan skop peranan kerap berlaku semasa memindahkan logik penukaran Assertion yang dibina dalam operasi SAML bertahun-tahun ke reka bentuk tuntutan OIDC. Langkah "menyenaraikan semua atribut SAML Assertion semasa dan membuat jadual pemetaan ke tuntutan standard OIDC + tuntutan tersuai" mesti sentiasa disertakan sebelum migrasi.
MFA Adaptif dan Pengesahan Step-up
MFA Adaptif ialah mekanisme yang menyesuaikan kekuatan pengesahan secara dinamik mengikut konteks permintaan. Secara biasa Passkey sahaja diluluskan, tetapi hanya apabila disambungkan dari peranti tidak dikenali, pada waktu lewat malam, atau dari negara yang pertama kali dilihat, pengesahan tambahan diminta. Pengesahan step-up adalah sub-set yang menilai semula kekuatan pengesahan sesi semasa sejurus sebelum operasi berisiko tinggi seperti "melihat data gaji", "deployment produksi", dan "eksport pukal data pelanggan", dan meminta pengesahan tambahan jika tidak mencukupi. Kaedah mengisytiharkan "operasi ini memerlukan acr=phr (phishing-resistant)" dengan tuntutan `acr` (Authentication Context Class Reference) OIDC adalah standard.
Yang paling sukar dalam reka bentuk ialah "nilai toleransi positif palsu". Terlalu ketat menghentikan kerja, terlalu longgar bermakna pelanggaran terlepas pandang. Peraturan pengalaman penulis ialah bermula dari "Passkey sahaja untuk peranti dikenali + geografi dikenali" dan "Passkey + step-up untuk peranti tidak dikenali", kemudian menyesuaikan dengan semakan bulanan kadar insiden dan kadar positif palsu.
Konflik Unik Syarikat Jepun: Nombor Peribadi dan Akaun Dikongsi
Apabila mempromosikan Passkey, SCIM, dan OIDC dalam syarikat Jepun, timbul konflik budaya yang tidak terdapat dalam dokumen vendor luar negara. Pertama, "pengendalian nombor pekerja dan nombor peribadi (My Number)". Nombor peribadi adalah terhad ketat dalam tujuan penggunaannya oleh Akta Nombor, dan nombor peribadi tidak boleh dimasukkan ke dalam tuntutan sub IdP atau externalId SCIM. Walau bagaimanapun, di lapangan terdapat sistem teras yang menghubungkan nombor pekerja dan nombor peribadi, dan insiden di mana nombor peribadi secara tidak sengaja dialirkan ke SaaS luar dalam reka bentuk penyegerakan SCIM berlaku. Senarai semak "atribut yang dilarang dari pendedahan luar" adalah wajib dalam jadual pemetaan atribut.
Kedua, konflik dengan "budaya akaun dikongsi". Dalam syarikat kecil dan sederhana Jepun, akaun dikongsi mengikut jawatan seperti `soumu@` dan `keiri@` kekal wujud. Kerana Passkey diikat kepada pengesah peribadi individu, jika Passkey ditetapkan pada akaun dikongsi, "siapa yang log masuk" tidak dapat dikesan. Strategi migrasi ialah memisahkan akaun dikongsi kepada akaun fungsi (Service Account) dan akaun peribadi, dan mereka bentuk semula supaya penerimaan e-mel perniagaan menggunakan akaun fungsi manakala log masuk menggunakan akaun peribadi. Jika mengutamakan kebolehbalikan log audit, tiada pilihan selain menghapuskan sepenuhnya log masuk dikongsi. Ketiga, "campuran peranti yang dipinjamkan syarikat dan BYOD", di mana operasi dua lapisan — hanya Passkey serentak untuk peranti yang diuruskan, kunci perkakasan wajib untuk BYOD — adalah praktikal.
Peta Jalan Migrasi
Peta jalan 12–18 bulan ditunjukkan. Peringkat 1 (0–3 bulan): penyediaan infrastruktur IdP, sokongan SAML/OIDC kedua-dua hala, inventori SaaS yang menyokong penerimaan SCIM. Peringkat 2 (3–6 bulan): deployment perintis Passkey, polisi awal MFA Adaptif, automasi SCIM untuk 10 SaaS prioriti. Peringkat 3 (6–12 bulan): deployment Passkey seluruh syarikat, pemansuhan berperingkat TOTP/SMS OTP, penyepaduan step-up ke dalam aplikasi. Peringkat 4 (12–18 bulan): larangan SAML baharu, keputusan migrasi SAML warisan ke OIDC atau penarikan diri, penghapusan penuh akaun dikongsi. Penjelasan kepada pengurusan paling berkesan dengan dua paksi: "anggaran kerugian disyaki AiTM" dan "pengurangan tenaga kerja respons audit". Infrastruktur operasi identiti yang menyatukan HR, ZTNA, dan kumpulan SaaS dengan IdP sebagai teras sedang dinaikkan dari projek kepada keupayaan tetap organisasi.