🔐 OTP 自动填充的实际工作原理（开发者深度解析）

Source: Dev.to

概览

一次性密码（OTP）自动填充看起来很神奇，但实际上它是操作系统层面的短信解析、应用或浏览器集成以及严格的安全规则的组合。

OTP 自动填充生命周期

1. 用户在应用中输入手机号码（例如 WhatsApp、Paytm）。
2. 后端生成 OTP 并通过短信网关发送。
3. 短信到达 设备。
4. 操作系统拦截 消息并解析其内容。
5. 若消息满足所需条件，OTP 会 展示给应用或浏览器。
6. 应用 自动填充（或建议）代码给用户。

关键洞察

• 应用 不能随意读取所有短信。
• 操作系统控制 对短信内容的访问，仅在满足必要条件时转发 OTP。

Android OTP 自动填充

SMS Retriever API（最安全）

由 Google 开发，此方式不需要应用拥有短信权限。

1. 应用生成一个 唯一的 11 位字符哈希。
2. 该哈希 附加在发送给用户的短信 中。
3. Android 读取收到的短信。
4. 若哈希匹配已安装的应用，OTP 会 自动传递 给该应用。

示例短信

Your OTP is 482913
FA+9qCX9VSu

SMS User Consent API

1. Android 显示一个 弹窗：“允许 AppName 读取此 OTP 吗？”
2. 用户批准后，OTP 会 传递给应用。

iOS OTP 自动填充

iOS 不允许应用直接读取短信。相反：

1. iOS 在收到的短信中检测 OTP 格式。
2. 在键盘上方显示一个 OTP 建议。
3. 用户点击该建议，代码 自动填充。

iOS 不需要特殊哈希。

浏览器中的 OTP 自动填充（Web 应用）

HTML Input 属性

现代浏览器（Chrome、Safari 等）将：

• 检测收到短信中的 OTP。
• 在键盘上方显示 建议。
• 用户选择建议后自动填充输入框。

WebOTP API（Chrome）

• 操作系统查找 4–8 位数字代码，并伴随关键词如 “OTP”、 “code”、 “verification”。
• 同时检查 应用名称或域名；域名必须与提供页面的站点匹配。
• 该 API 仅在 HTTPS 安全页面上工作。

安全考虑

• Android：需要匹配的 签名哈希（SMS Retriever）或明确的 用户同意（User Consent API）。
• iOS：没有直接的短信访问权限；OTP 以键盘建议形式呈现。
• WebOTP：仅在 HTTPS 上运行，并验证域名以防钓鱼。

---

有关实现细节、后端设计和示例代码，请参阅 GitHub 上的项目仓库。