Passkey B2B 元年：从消费端走向企业端
- ～2024 年由 Apple、Google、Microsoft 联合推进的 Passkey，最初作为面向消费者的认证手段得到普及。然而自 2025 年下半年起，B2B 采用快速推进，2026 年可称为「Passkey B2B 部署元年」。Okta、Entra ID、Google Workspace、1Password Business 均已同时支持跨设备 Passkey 与同步 Passkey，并与 FIDO2 合规安全密钥（YubiKey 5C、Google Titan）并行运作的设计已趋于成熟。
Passkey 在 B2B 中全面落地的最大原因是抗钓鱼性。2024～2025 年，针对日本企业的 AiTM（Adversary-in-the-Middle）钓鱼工具箱急剧增多。传统的 TOTP 或 SMS OTP 在中间人代理截取认证会话的攻击面前十分脆弱，国内多家大型 SaaS 发生了数千账户一夜沦陷的事件。Passkey（WebAuthn）因域名绑定机制，在钓鱼网站上无法完成签名，从协议层面对 AiTM 具有结构性抵抗力。「不靠运营注意，而是由协议保障」这一点，成为管理层决策的依据。
同步 Passkey（通过 iCloud Keychain、Google Password Manager）与设备绑定 Passkey（封闭在 YubiKey 等硬件中）的权衡仍是持续讨论的议题。金融、国防领域倾向于设备绑定，大范围员工部署则以同步 Passkey 为现实选择。NIST SP 800-63B 2025 年修订版将同步 Passkey 认定为 AAL2，为策略制定提供了支撑。
WebAuthn 实现的陷阱与账户恢复
最先遇到的问题是 RP ID（Relying Party ID）的设计。RP ID 以域名为单位，因此 `corp.example.jp` 与 `portal.example.jp` 需要分别注册不同的 Passkey。如需统一，应将父域名 `example.jp` 作为 RP ID，但若与营销网站共享父域名，需谨慎评估影响。
账户恢复是 Passkey 运营中最大的难题。若疏于设计恢复方案，备用手段往往保留了弱认证方式（邮件 OTP、SMS OTP），安全强度实际上被降低至残存备份的级别。推荐采用三层设计：轻度恢复（从其他设备重新登录）通过同步 Passkey 自动解决；中度恢复（所有设备丢失）需管理员审批 + 本人身份证明文件；重度恢复（怀疑 ID 被篡改）必须进行离线本人确认。重度恢复不应经由客服进行，2024 年实际发生过通过客服进行社会工程攻击的案例。
SCIM 与自动化预配
SCIM 2.0 的自动化预配已不再是可选项，而是必要前提。从 IdP 向各 SaaS 进行 SCIM 同步，用户添加、属性更新、停用均可实时传播。主流 SaaS（Salesforce、Slack、Notion、GitHub Enterprise、Atlassian）均已标准提供 SCIM 2.0，接收侧实现质量较 2024 年也大幅提升。
SCIM 运营中容易忽视的是属性映射设计。将 IdP 侧的部门、职位、雇用类型映射至 SaaS 侧的组和权限角色的对照表，需要由 HR 与信息系统部门联合维护。Okta Workflows、Entra Lifecycle Workflows 提供了无代码 UI，通过 IF 条件链进行表达是主流方式。依赖脚本的属性转换，往往半年后便无法跟上变更，是典型的反模式。从 CSV 日同步迁移出来的计划，在 2026 年的内部审计中被要求呈现的案例正在增加。
从 SAML 迁移至 OIDC：为何是现在
SAML 长期以来是 B2B SSO 的标准，但截至 2026 年，新项目已将 OIDC 作为首选。原因有三：第一，在移动端/SPA 支持方面，SAML 的 XML 重定向与使用 PKCE 的 OIDC 相比在原生移动端上更为繁琐；第二，在签名/加密复杂性方面，SAML 的 XML Signature 规范范围广泛，历史上因实现差异引发的漏洞（XML Signature Wrapping 攻击等）频繁出现；第三，可在结构上将认证（ID Token）与 API 授权（Access Token）分离，在微服务环境下的权限设计更为清晰。
但全面废除 SAML 并不现实。SAP SuccessFactors、Workday 以及部分 Oracle Cloud 仍以 SAML 为唯一 SSO 方式。迁移策略应为「新建项目使用 OIDC，现有 SAML 暂时维持，将 IdP 整合为兼容两者的平台」。迁移中最常遇到的难题是「属性映射差异」——将长期 SAML 运营中积累的 Assertion 转换逻辑迁移至 OIDC claim 设计时，组名冲突和角色范围不匹配频繁发生。迁移前务必插入「列举现有 SAML Assertion 的全部属性，并制作到 OIDC 标准 claim + 自定义 claim 的映射表」这一步骤。
Adaptive MFA 与 step-up 认证
Adaptive MFA 是根据请求上下文动态调整认证强度的机制。通常仅使用 Passkey 放行，但在从未知设备、深夜、首次出现的国家发起连接时，才要求追加认证。Step-up 认证是其子集，在「查看薪资数据」「生产部署」「批量导出客户数据」等高风险操作前，重新评估当前会话的认证强度，不足时要求追加认证。通过 OIDC 的 `acr`（Authentication Context Class Reference）claim 声明「此操作需要 `acr=phr`（phishing-resistant）」是标准做法。
设计上最难处理的是「误报的可接受程度」。过于严格则业务停滞，过于宽松则侵害被忽视。根据笔者的经验，从「已知设备 + 已知地理位置时仅需 Passkey」「未知设备时需要 Passkey + step-up」开始，通过每月审查历史事件与假阳性率进行调整。
日本企业的特有冲突：个人编号与共享账户
在日本企业中推进 Passkey、SCIM、OIDC 时，会出现海外厂商文档中没有提及的文化冲突。第一是「员工编号与个人番号（My Number）的处理」。个人番号受《番号法》严格限制使用目的，不得将个人番号放入 IdP 的 sub claim 或 SCIM 的 externalId 中。然而，现场仍存在将员工编号与个人番号关联的核心系统，在 SCIM 同步设计中误将个人番号发送至外部 SaaS 的事故时有发生。属性映射表中必须设置「禁止外部流出属性」检查清单。
第二是与「共享账户文化」的冲突。日本的中小企业普遍保留如 `soumu@`、`keiri@` 等按职位设置的共享账户。Passkey 绑定于个人认证器，若对共享账户设置 Passkey，则无法追溯「是谁登录了」。迁移策略是将共享账户分离为功能账户（Service Account）和个人账户，业务邮件接收使用功能账户，登录使用个人账户的设计重构。若优先考虑审计日志的可追溯性，则只能全面废除共享登录。第三是「公司统一配发设备与 BYOD 混用」的问题，由管理设备允许同步 Passkey、BYOD 必须使用硬件密钥的两层运营是现实选择。
迁移路线图
以下是 12～18 个月的路线图。第一阶段（0～3 个月）：整备 IdP 基础、支持 SAML/OIDC 双向兼容、梳理支持 SCIM 接收的 SaaS 清单。第二阶段（3～6 个月）：Passkey 试点部署、Adaptive MFA 初期策略、优先将 10 个 SaaS 实现 SCIM 自动化。第三阶段（6～12 个月）：全公司 Passkey 部署、TOTP/SMS OTP 的逐步废除、step-up 认证嵌入应用。第四阶段（12～18 个月）：禁止新建 SAML、对遗留 SAML 进行 OIDC 迁移或退出判断、全面废除共享账户。向管理层说明时，「AiTM 的预期损失金额」与「审计应对工时削减」这两个维度最为有效。以 IdP 为核心整合 HR、ZTNA、SaaS 群的身份运营基础设施，正从单项目升格为组织的常态化能力。