otpauth 二维码是什么？2FA App 读到的其实是这些内容
很多网站开启两步验证时，会让你用 Google Authenticator、Microsoft Authenticator 或其他验证器 App 扫一个二维码。这个二维码通常不是一张神秘图片，里面大多是一段 otpauth:// 开头的文本。
看懂它很有用：
- 手机扫不了码时，你知道“手动输入密钥”到底是什么。
- 自己调试 TOTP 集成时，可以判断为什么验证码不通过。
- 想在浏览器里临时测试 2FA 密钥时，能判断工具是否安全。
otpauth URI 是什么？
otpauth:// URI 是验证器 App 用来描述一次性验证码账户的格式。Google Authenticator 文档里的常见格式类似这样：
otpauth://totp/Issuer:[email protected]?secret=BASE32SECRET&issuer=IssuerIANA 也把 otpauth 列为一个 provisional URI scheme，用于 Google Authenticator、Microsoft Authenticator 这类 App。实际生成验证码时，最常见的是 TOTP，也就是 RFC 6238 描述的基于时间的一次性密码算法。
里面哪些字段最重要？
| 字段 | 示例 | 作用 |
|---|---|---|
| 类型 | totp | 是否基于时间生成验证码。现在常见验证器码基本都是 TOTP。 |
| 账户标签 | BaseToolbox:[email protected] | App 列表里显示的账户名称。 |
| 密钥 | JBSWY3DPEHPK3PXP | 用来生成验证码的 Base32 密钥，要当成密码保管。 |
| 发行方 | BaseToolbox | 服务名称，方便 App 展示和分组。 |
| 周期 | 30 | 每个验证码有效多少秒，常见是 30 秒。 |
| 位数 | 6 | 验证码几位数，常见是 6 位。 |
| 算法 | SHA1 | 哈希算法，SHA-1 是常见默认值，主要为了兼容。 |
并不是每个二维码都会写全所有参数。没写时，验证器 App 通常会使用默认值。
为什么 App 和网站能生成同一个验证码？
TOTP 的核心很简单：网站和你的验证器 App 共享同一个密钥，并且都使用当前时间。网站在你开启 2FA 时保存密钥，App 扫码后也保存同一个密钥。每个时间窗口里，双方用同一套算法算出一个短数字码。
所以手机时间不准会导致验证码失败。如果设备时间和服务器时间差太多，App 显示的码看起来正常，但网站会拒绝。
可以把 otpauth 密钥粘到在线工具里吗？
前提是这个工具必须在浏览器本地处理。2FA 密钥能生成未来的登录验证码，本质上要像密码一样保管。
粘贴密钥之前，至少确认这几件事：
- 工具是否明确说明密钥留在浏览器本地？
- 页面加载后断网，是否仍然能生成验证码？
- 是否避免上传、同步、日志记录或远程 API 请求？
- 你是不是只用它临时测试或排错，而不是长期保存账户密钥？
BaseToolbox 的 2FA 验证码生成器用于浏览器本地计算 TOTP，适合临时测试 setup key、检查二维码内容，或在桌面端用已知密钥生成验证码。
验证码不通过时先检查这些
- 密钥有没有复制错。Base32 密钥里字母和数字很容易看错。
- 服务要求的是 6 位还是 8 位验证码。
- 周期是不是 30 秒，除非服务明确写了别的值。
- 手机或电脑时间是否开启自动校准。
- 如果是自己拼 URI，
issuer和账户标签是否写清楚。
一句话总结
otpauth:// 二维码本质上是验证器 App 的 setup link，里面通常包含 TOTP 密钥、账户名称、服务名称和可选的验证码参数。拿到密钥的人就能生成未来验证码，所以只应该在可信的本地处理工具里测试。
实用流程
把转换结果当作需要验证的值，而不是直接复制的最终答案。先判断输入格式，再转换，然后放到真实环境里测试。通用小工具最常见的问题是值“看起来差不多”，但单位、时区、编码、版本或字符集不对。
保留一个已知样例。时间戳、UUID、Base64、URL 编码、时区转换这类值，如果会进入生产环境，最好附一个测试用例或备注，方便之后复查同一个假设。
检查清单
| 检查项 | 为什么重要 | |---|---| | 输入格式 | 看起来相似的值可能单位或编码不同。 | | 输出环境 | JavaScript、API、数据库、CSS 需要的形态可能不同。 | | 边界情况 | 空字符串、非法字符、边界日期最容易暴露问题。 | | 复制准确性 | 少一个字符就可能改变 UUID、Base64、URL 或时间戳。 |
常见问题
可以不测试直接使用转换值吗？
不建议。工具能快速得到结果，但正式使用前仍应在目标系统或已知样例里验证。
使用场景示例
调试 API 值时，先写下原始输入、期望输出和消费它的系统，再转换并回到真实环境测试。时间戳可能 UTC 正确但本地显示不同；Base64 可能能解码，但内容类型并不是你以为的文件。
通用小工具的价值，是把这些隐藏假设变得可见，而不是让人跳过验证。
参考资料：