Android无密码登录与数字凭证实战指南

Google与Aptura在最新技术分享中系统展示了Android平台身份认证的演进路径：从Passkey全面替代密码，到设备迁移的零点击登录，再到数字凭证的生态构建。这不只是API的更新，更是整个应用身份体系的迁移窗口期。

密码的终结：为什么现在才真正可行

Aptura CTO Tom Colvin在开场就给出了鲜明判断：密码已死，或者说它早该死。密码的脆弱性来自结构性缺陷——即使安全存储，也无法抵御钓鱼、服务器泄露和撞库攻击。行业曾试图用复杂度规则（特殊字符、数字、强制轮换）来补救，结果适得其反：越复杂的密码越容易被写在便签上，强制轮换反而催生不安全行为。短信二次验证也已被SIM交换等攻击证明不可靠。

Passkey基于FIDO标准的公私钥密码学，从根本上改变了威胁模型：它天然抗钓鱼，不会在服务器泄露中暴露，绑定设备屏锁（多数场景下即生物识别），同时改善了用户体验——跨平台统一、无需记忆。Colvin的宣言很直接：迁移到无密码世界的工具已经在手上了。

FIDO 标准与 WebAuthn 是理解 Passkey 的技术前提。FIDO（Fast IDentity Online）联盟制定了一系列无密码认证规范，其核心思想是用非对称密钥对替代共享密钥（密码）。注册时设备生成密钥对，私钥永不离开安全硬件（如 TEE 或 Secure Enclave），公钥交给服务器；登录时服务器发送挑战，设备用私钥签名，服务器用公钥验签。由于私钥从不传输，钓鱼网站无法获取可重放的凭证，服务器泄露也不会危及用户账户。WebAuthn 是 W3C 与 FIDO 合作制定的 Web 端 API 标准，Android 的 Credential Manager 在底层与之对齐，因此 Passkey 可以跨 Web 与原生应用使用。

SIM 交换攻击 是短信二次验证失效的典型原因。攻击者通过社会工程或运营商内部漏洞，将受害者手机号转移至自己控制的 SIM 卡，从而截获所有短信验证码。此外还有 SS7 信令漏洞、短信拦截木马等路径。这就是为什么基于共享秘密的带外通道（短信、邮件验证码）在威胁模型中应被视为弱因子，而基于公私钥的 Passkey 天然免疫此类攻击。

Credential Manager：一个API统一所有认证方式

Android端的核心抓手是Jetpack Credential Manager，支持回溯到Android 4.4，Passkey支持从Android 9开始。它提供单一统一API，同时覆盖Passkey、Google联合登录等传统方式，并保留密码回退路径。

开发者的收益在于UI由系统接管：调用API后，Credential Manager负责弹出选择界面、完成加密操作并安全返回凭证。注册和登录流程的代码差异极小——注册时构造CreatePublicKeyCredentialRequest并调用CredentialManager.createCredential，登录时构造GetPublicKeyCredential并调用CredentialManager.getCredential，全程无需编写任何UI代码。

这个设计顺带解决了一个长期痛点：用户不必再回忆上次用了哪种登录方式。系统会把最常用的选项推到前面，其余作为备份呈现。Colvin指出这不只是体验问题，它直接造成账户找回成本和不必要的商业损失，比如购物车放弃。

Conditional create 与 conditional get 是 Credential Manager 中两个容易被混淆的概念。Conditional create（条件创建）指在用户使用密码等传统方式登录时，系统在自动填充流程中静默创建 Passkey，用户无需额外操作；它要求凭证提供方支持自动填充集成，且代码中需设置 isConditional = true。Conditional get（条件获取）则是在登录表单聚焦时，系统在键盘上方以自动填充建议的形式展示可用 Passkey，用户点击即可登录。两者共同构成"机会式升级"的技术基础，但前者用于注册侧，后者用于登录侧，开发者需要分别接入。

CreatePublicKeyCredentialRequest 与 GetPublicKeyCredentialRequest 分别对应注册和登录两个方向。前者携带 relying party 信息、用户标识、挑战值以及是否要求用户验证（UV）等参数；后者携带 relying party ID 和挑战值。Credential Manager 负责将这些请求路由到合适的凭证提供方，并返回 CreatePublicKeyCredentialResponse 或 GetCredentialResponse。理解这两个请求对象的字段，是排查"为什么系统没有弹出 Passkey 选项"类问题的关键。

五步迁移路线：从机会式升级到彻底移除密码

Colvin给出的落地路径很务实，分五个步骤。前两步针对存量密码用户：先用conditional create做机会式升级——当用户刚用密码登录且被支持的凭证提供方自动填充时，后台静默生成Passkey，不打断工作流，Google Password Manager会发通知确认，其他管理器行为可能不同。代码上只需设置isConditional = true并包在try-catch中静默处理失败。如果没有机会触发，再通过应用内邀请逐步提升Passkey设置的曝光。

当分析数据显示绝大多数用户已使用Passkey后，对新用户强制Passkey。后三步处理老用户：先提供清晰的删除密码选项（手动），再通过应用内通知配合教育文案推动删除，最后把删除从opt-in切换为opt-out，直至有数据信心后彻底移除密码流程。这条路径的关键在于用数据驱动每一步的推进节奏，而非一刀切。

Signal API：让凭证提供方感知失效状态

一个容易被忽视的细节：当用户在某应用或网站撤销Passkey后，凭证提供方未必知晓，下次登录仍会展示已失效的凭证，导致登录被拒。Signal API让应用可以把这类状态同步给提供方，使其更新自身、不再展示失效凭证。用户名或显示名变更需要同步时同理。这补上了Passkey生命周期管理的一环。

零点击登录：2027年4月的Play商店硬性要求

Google高级Android开发者关系工程师Chipping Yeh把话题转向设备迁移。用户旅程中流失最大的环节往往发生在新机切换时。Google Play将从2027年4月起要求应用满足零点击登录要求，以维持完整发布能力和商店可见性。所谓零点击，指用户迁移到新设备后无需在应用中手动重新认证。

实现主路径是Restore Credentials API（通过Credential Manager）。应用在用户登录后的某个时点后台生成restore key，按用户备份设置存于本地或云端；新设备设置过程中凭证静默迁移；应用首次启动时调用Credential Manager完成登录。若希望应用在设置后立即恢复而无需用户打开，可实现自定义备份代理。

Uber已在Uber Rider应用中落地该能力，据分享估算将每天节省约400万次平均登录。这个量级说明设备迁移摩擦不是小问题，而是留存和运营成本的直接来源。

Restore Credentials API 的核心是 restore key 的生成与迁移时机。应用应在用户完成登录后的某个稳定时点（而非登录瞬间，以避免失败登录也生成 key）调用 API 生成 restore key，并将其与当前用户绑定。存储位置取决于用户的备份设置：若用户启用了端到端加密备份，key 存于云端；否则仅存本地。新设备设置时，系统根据备份配置决定是否迁移 key；应用首次启动时，Credential Manager 检查是否存在对应的 restore key，若存在则直接完成登录，无需用户输入任何信息。

自定义备份代理 用于满足"设置完成后立即恢复"的场景。默认情况下，应用需要被用户首次打开才会触发恢复；而实现备份代理后，系统可以在设备设置阶段就调用应用的恢复逻辑，使应用在用户尚未主动打开前即处于已登录状态。这要求应用声明相应的备份代理组件并处理系统回调，接入复杂度高于基础 Restore Credentials，但对留存敏感型应用价值明显。

数字凭证：三方模型与端到端的安全设计

Yeh接着介绍了Digital Credentials API。数字凭证是密码学可验证的数字文档，存储在设备上的数字钱包中，可由设备内其他应用请求，也可通过二维码等混合方式对外出示。它涉及三方：发行方（issuer）、持有方（holder，即数字钱包）和验证方（verifier）。三方交互由Credential Manager协调。

安全设计贯穿每一步。发行方侧：持有方需用可验证证书链证明自身身份与设备安全性，并生成硬件绑定密钥对，通过Android密钥认证把公钥交给发行方验证硬件合法性，发行方将该公钥写入凭证，使凭证绑定单一设备。持有方侧：只向Credential Manager注册凭证元数据，真实用户数据不注册、不暴露给Google；即使系统在匹配钱包时也不揭示钱包内容。验证方侧：可检查响应是否由原始持有方针对本次请求新鲜生成、是否用持有方设备绑定密钥签名（包括请求一次性token并校验origin），并验证发行方证书确认来源可信。

一句话概括：发行方获得硬件保证，持有方掌握分享控制权，验证方获得发行方与持有方的密码学证明，用户保留完整的数据分享同意权。

Android 密钥认证（Key Attestation） 是数字凭证发行方获得硬件保证的底层机制。设备在生成密钥对时，可以由硬件支持的密钥库（Keystore）颁发一份证书链，其中包含设备型号、系统版本、安全补丁级别以及密钥是否硬件绑定等信息。发行方验证该证书链，即可确认公钥确实产生于一台真实、未被篡改的 Android 设备，而非模拟器或软件伪造环境。这正是"凭证绑定单一设备"的技术依据。

数字凭证与 Passkey 的区别 值得厘清：Passkey 是用于向某个特定 relying party 认证的密钥对，本质是登录凭证；数字凭证则是可验证的数字文档（如学历、驾照、年龄证明、已验证邮箱），由发行方签发、用户持有、可向任意验证方选择性出示。前者解决"我是谁"，后者解决"我持有某机构认证的某项属性"。两者都基于密码学，但信任模型和数据流向不同，数字凭证更强调最小披露和用户同意。

已可用的两类验证场景：邮箱与手机号

数字凭证API目前已有可直接落地的用例。邮箱验证直接从设备上已登录的Gmail取用，作为Google验证的数字凭证呈现给应用，省去一次性密码或魔法链接。用户仅在Credential Manager底部弹窗中一键同意，数据不离开应用。Google在此场景中同时是发行方和持有方。

手机号验证同理，取代短信OTP的摩擦与脆弱性。此场景中发行方是SIM卡对应的运营商，持有方是Android，用户经由Google Telephony取号。流程有一处独特环节：号码从Google Telephony取出后以加密状态传给运营商或聚合商解密并回传至应用后端，同时完成计费。运营商只对成功验证收费，走数据或Wi-Fi通道，可靠性显著高于短信。演示中使用Firebase作为运营商聚合商，多SIM用户可选择要分享的号码，全程不离开应用。

开发者该做什么

分享者的结论很明确：所有能力均已上线可用。短期内应优先接入Credential Manager并优化Passkey流程，用conditional create低成本升级存量用户；把2027年4月的零点击登录要求列入路线图，评估Restore Credentials的接入；同时关注数字凭证在邮箱和手机号验证上的替代价值，这两个场景的改造收益最直接。身份体系的迁移窗口已经打开，越早启动，越能用数据驱动后续每一步的节奏。