Năm đầu tiên của Passkey B2B: Từ tiêu dùng sang enterprise
Passkey mà Apple, Google và Microsoft cùng thúc đẩy trong 2022-2024 ban đầu lan rộng như phương tiện xác thực dành cho người tiêu dùng. Tuy nhiên, từ nửa sau năm 2025, việc áp dụng B2B tiến nhanh, và năm 2026 có thể gọi là "năm đầu tiên triển khai Passkey B2B". Tất cả Okta, Entra ID, Google Workspace và 1Password Business đều hỗ trợ cả Cross-Device Passkey và synchronized Passkey, và đã trưởng thành đến thiết kế có thể vận hành song song với khóa bảo mật tuân chuẩn FIDO2 (YubiKey 5C, Google Titan).
Lý do lớn nhất Passkey được triển khai chính thức trong B2B là khả năng chống phishing. Trong 2024-2025, các bộ kit phishing AiTM (Adversary-in-the-Middle) nhắm mục tiêu doanh nghiệp Nhật Bản tăng nhanh. TOTP hoặc SMS OTP truyền thống dễ bị tấn công chiếm đoạt phiên xác thực qua proxy người đứng giữa, và đã xảy ra nhiều vụ việc hàng nghìn tài khoản của SaaS lớn trong nước bị xâm phạm trong một đêm. Passkey (WebAuthn) có tính chống AiTM theo cấu trúc vì chữ ký không thành lập trên site phishing do domain binding. Điểm "được đảm bảo bởi giao thức" chứ không phải "cẩn thận trong vận hành" đã trở thành cơ sở quyết định kinh doanh.
Vấn đề đánh đổi giữa synchronized Passkey (qua iCloud Keychain, Google Password Manager) và device-bound Passkey (giới hạn trong YubiKey v.v.) vẫn là điểm tranh luận tiếp tục. Lĩnh vực tài chính và quốc phòng ưa device-bound, và synchronized Passkey thực tế hơn cho việc triển khai diện rộng cho nhân viên. Việc NIST SP 800-63B sửa đổi năm 2025 công nhận synchronized Passkey là AAL2 đã trở thành cơn gió thuận cho việc xây dựng policy.
Cạm bẫy triển khai WebAuthn và khôi phục tài khoản
Điều bị vấp đầu tiên là thiết kế RP ID (Relying Party ID). Vì RP ID theo đơn vị domain, `corp.example.jp` và `portal.example.jp` cần đăng ký Passkey riêng. Nếu muốn tích hợp, cần đặt domain cha `example.jp` làm RP ID, nhưng với tổ chức chia sẻ domain cha với site marketing cần đánh giá cẩn thận tác động.
Khôi phục tài khoản là khó khăn lớn nhất trong vận hành Passkey. Nếu bỏ qua thiết kế khôi phục, phương tiện backup là xác thực yếu (email OTP, SMS OTP) được duy trì và cường độ bảo mật bị kéo xuống theo backup còn lại. Thiết kế 3 tầng được khuyến nghị. Khôi phục nhẹ (đăng nhập từ thiết bị khác) được giải quyết tự động bằng synchronized Passkey, khôi phục trung bình (mất tất cả thiết bị) cần phê duyệt quản trị viên + xác minh giấy tờ cá nhân, khôi phục nặng (nghi ngờ giả mạo ID) bắt buộc xác minh cá nhân offline. Việc không đưa khôi phục nặng qua CS cũng quan trọng, vì việc đột phá social engineering CS đã thực sự xảy ra năm 2024.
SCIM và tự động hóa provisioning
Provisioning tự động bằng SCIM 2.0 không còn là lựa chọn mà là tiền đề. Bằng cách đồng bộ SCIM từ IdP đến từng SaaS, việc thêm người dùng, cập nhật thuộc tính và vô hiệu hóa được truyền tải theo thời gian thực. Các SaaS chính (Salesforce, Slack, Notion, GitHub Enterprise, Atlassian) đều cung cấp SCIM 2.0 tiêu chuẩn, và chất lượng triển khai bên tiếp nhận cũng cải thiện đáng kể so với năm 2024.
Điều thường bị bỏ qua trong vận hành SCIM là thiết kế mapping thuộc tính. Hãy làm thành hình thức mà cả HR và bộ phận IT có thể cùng duy trì bảng map thuộc tính phòng ban/chức vụ/loại hình công việc phía IdP sang nhóm và role quyền phía SaaS. Okta Workflows và Entra Lifecycle Workflows có UI no-code, và phương thức biểu diễn bằng chuỗi lệnh IF là chủ đạo. Chuyển đổi thuộc tính phụ thuộc script sẽ trở thành pattern điển hình không theo kịp thay đổi sau 6 tháng. Kế hoạch thoát khỏi đồng bộ CSV hàng ngày đang được yêu cầu trình bày trong kiểm toán nội bộ ngày càng nhiều năm 2026.
Từ SAML sang OIDC: Tại sao bây giờ?
SAML là tiêu chuẩn lâu dài của B2B SSO, nhưng tính đến năm 2026, dự án mới lấy OIDC làm lựa chọn đầu tiên. Có 3 lý do. Thứ nhất về hỗ trợ mobile/SPA, redirect XML của SAML phức tạp hơn trong native mobile so với OIDC sử dụng PKCE. Thứ hai về độ phức tạp của ký và mã hóa, đặc tả XML Signature của SAML rộng và lịch sử có nhiều lỗ hổng bảo mật do chênh lệch triển khai (tấn công XML Signature Wrapping v.v.). Thứ ba vì có thể phân tách cấu trúc xác thực (ID Token) và ủy quyền API (Access Token), thiết kế quyền trong môi trường microservice trở nên rõ ràng.
Tuy nhiên, xóa bỏ hoàn toàn SAML không thực tế. SAP SuccessFactors, Workday, một số Oracle Cloud chỉ có SAML là SSO duy nhất. Chiến lược chuyển dịch là "mới là OIDC, SAML hiện có duy trì tạm thời, tập trung IdP vào nền tảng hỗ trợ cả hai". Điều bị vấp trong chuyển dịch là "chênh lệch mapping thuộc tính", và khi kế thừa logic chuyển đổi Assertion được xây dựng qua nhiều năm vận hành SAML sang thiết kế OIDC claim, xung đột tên nhóm và không khớp role scope thường xảy ra. Trước khi chuyển dịch, nhất thiết phải có giai đoạn "liệt kê toàn bộ thuộc tính SAML Assertion hiện tại và tạo bảng ánh xạ sang OIDC standard claim + custom claim".
Adaptive MFA và step-up authentication
Adaptive MFA là cơ chế điều chỉnh động cường độ xác thực theo ngữ cảnh request. Thông thường chỉ cần Passkey, nhưng chỉ yêu cầu xác thực bổ sung khi kết nối từ thiết bị lạ, ban đêm, từ quốc gia lần đầu, v.v. Step-up authentication là tập con của nó, đánh giá lại cường độ xác thực phiên hiện tại ngay trước các thao tác rủi ro cao như "xem dữ liệu lương", "deploy sản xuất", "export hàng loạt dữ liệu khách hàng", và yêu cầu xác thực bổ sung nếu thiếu. Phương thức chuẩn là khai báo claim `acr` (Authentication Context Class Reference) của OIDC "thao tác này yêu cầu acr=phr (phishing-resistant)".
Khó khăn nhất trong thiết kế là "ngưỡng chấp nhận dương tính giả". Quá nghiêm ngặt sẽ dừng nghiệp vụ, quá lỏng lẻo sẽ bỏ qua xâm phạm. Theo kinh nghiệm của tác giả, bắt đầu từ "thiết bị đã biết + địa lý đã biết chỉ cần Passkey", "thiết bị lạ cần Passkey + step-up" và điều chỉnh qua review hàng tháng về lịch sử sự cố và tỷ lệ dương tính giả.
Xung đột đặc thù doanh nghiệp Nhật Bản: Số cá nhân và tài khoản dùng chung
Khi thúc đẩy Passkey, SCIM và OIDC tại doanh nghiệp Nhật Bản, các xung đột văn hóa không có trong tài liệu nhà cung cấp nước ngoài nổi lên. Thứ nhất là "xử lý mã nhân viên và số cá nhân (My Number)". Số cá nhân bị giới hạn mục đích sử dụng nghiêm ngặt theo Luật Số, và không được đưa số cá nhân vào sub claim của IdP hay externalId của SCIM. Tuy nhiên trên thực tế, hệ thống cốt lõi liên kết mã nhân viên và số cá nhân còn lại, và đang xảy ra sự cố vô tình chảy số cá nhân ra SaaS bên ngoài trong thiết kế đồng bộ SCIM. Bảng mapping thuộc tính cần checklist "thuộc tính cấm chảy ra ngoài".
Thứ hai là xung đột với "văn hóa tài khoản dùng chung". Các tài khoản chung theo chức vụ như `soumu@`, `keiri@` vẫn còn trong doanh nghiệp vừa và nhỏ đến trung bình ở Nhật Bản. Vì Passkey gắn với thiết bị xác thực của cá nhân, nếu đặt Passkey cho tài khoản dùng chung sẽ không thể truy vết "ai đã đăng nhập". Chiến lược chuyển dịch là tổ chức lại thiết kế phân tách tài khoản dùng chung thành tài khoản chức năng (Service Account) và tài khoản cá nhân, nghiệp vụ nhận email bằng tài khoản chức năng, đăng nhập bằng tài khoản cá nhân. Nếu ưu tiên tính có thể đảo ngược của audit log thì chỉ có cách xóa hoàn toàn đăng nhập dùng chung. Thứ ba là "hỗn hợp thiết bị cho mượn của công ty và BYOD", với vận hành hai tầng synchronized Passkey chỉ cho thiết bị được quản lý, phần cứng key bắt buộc cho BYOD là thực tế.
Lộ trình chuyển dịch
Chúng tôi trình bày lộ trình 12~18 tháng. Giai đoạn 1 (0~3 tháng): chuẩn bị nền tảng IdP, kiểm kê SaaS hỗ trợ SAML/OIDC cả hai, hỗ trợ tiếp nhận SCIM. Giai đoạn 2 (3~6 tháng): triển khai thí điểm Passkey, policy Adaptive MFA ban đầu, tự động hóa SCIM 10 SaaS ưu tiên. Giai đoạn 3 (6~12 tháng): triển khai toàn bộ Passkey, loại bỏ dần TOTP/SMS OTP, tích hợp step-up vào ứng dụng. Giai đoạn 4 (12~18 tháng): cấm mới SAML, chuyển dịch hoặc quyết định rút lui SAML legacy sang OIDC, xóa bỏ hoàn toàn tài khoản dùng chung. Giải thích cho cấp quản lý hiệu quả bằng 2 trục "ước tính thiệt hại giả định AiTM" và "giảm thiểu công việc đối phó kiểm toán". Nền tảng vận hành danh tính tích hợp IdP làm trụ cột với nhóm HR, ZTNA và SaaS đang được nâng cấp từ cấp độ dự án lên năng lực thường trực của tổ chức.