GitHub安全密钥、Passkey与Mobile验证在双重验证中的不同角色
在GitHub的两步验证（2FA）体系中，安全密钥、Passkey与GitHub Mobile常被并列为可选方式，但它们在登录流程中承担的角色并不相同。根据GitHub Docs的说明，配置2FA时可以先选择TOTP应用或短信作为基础方式，之后才能把安全密钥添加为备用的第二因素；Passkey和GitHub Mobile同样要求账户已经通过TOTP移动应用或短信完成2FA配置。理解这一前置条件，是区分三者定位的起点。文档还提示，自2023年3月起，GitHub要求所有在GitHub.com上贡献代码的用户启用一种或多种形式的2FA；符合条件者会收到通知邮件，并进入为期45天的注册期。若未收到通知，则不属于被强制要求的群体，但官方仍强烈建议启用。
安全密钥在文档中被明确定位为“第二因素”。它属于WebAuthn凭据，但与Passkey不同，不要求用户验证，只需确认用户在场，因此必须与密码配合使用。注册安全密钥的前提是已通过TOTP应用或短信启用2FA；这样即使安全密钥丢失，仍可用手机上的验证码登录。文档还提醒，并非所有FIDO认证器都能用作Passkey，但这类认证器仍可注册为安全密钥。换言之，安全密钥更像是密码之外的一道附加证明，而不是独立的登录凭据。
Passkey的定位则更进一步。文档指出，Passkey让用户无需输入密码即可在浏览器中安全登录GitHub；如果账户已启用2FA，Passkey可同时满足密码和2FA两项要求，实现单步登录。若未启用2FA，使用Passkey可跳过通过电子邮件验证新设备的步骤。Passkey还可用于sudo模式和重置密码。Windows Hello、Face ID或Touch ID等平台认证器可以注册为Passkey。但文档同时强调，添加Passkey前必须已通过TOTP移动应用或短信配置2FA，说明Passkey在GitHub的当前流程中并非从零开始的唯一凭据。
GitHub Mobile的2FA机制又有所不同。文档说明，在浏览器登录GitHub账户时可以使用GitHub Mobile完成2FA；它不依赖TOTP，而是使用公钥密码学保护账户。配置前提同样是已设置TOTP应用或短信，之后安装GitHub Mobile、登录账户并确保能接收推送通知，即可用该设备进行2FA。若未来无法访问GitHub Mobile，仍可使用安全密钥或TOTP应用登录。可见Mobile验证依赖已登录的移动应用与推送通道，属于另一种第二因素形态，而非Passkey那样的无密码单步方案。
三者之外，文档还给出两项通用约束。其一，启用2FA后账户进入28天检查期，用户可在该期间成功执行2FA以离开检查期；否则第28天会在现有GitHub会话中被提示执行2FA，若无法通过，须使用提供的快捷方式重新配置2FA以保留访问权限。其二，企业托管用户若不属于设置用户，不能自行配置2FA，须由管理员在身份提供方（IdP）上配置。此外，若组织要求2FA，成员或计费经理在禁用2FA期间无法访问该组织资源；外部协作者在禁用2FA后还会失去对组织私有仓库私有分支的访问，须重新启用2FA并联系组织所有者恢复。文档强烈建议使用TOTP应用而非短信，并以安全密钥作为备用方式，理由是短信易被拦截、不抗钓鱼、送达不可靠且并非所有国家都支持。这些限制共同说明：安全密钥、Passkey与Mobile验证各有适用边界，选择时应先确认账户是否已完成基础2FA配置，再结合自身设备与组织要求决定。