二维码不等于 TOTP：如何读懂 otpauth URI 与兼容参数

验证器页面上的二维码只是编码载体。它可能包含 TOTP 配置也可能是登录确认、设备绑定、迁移包或平台专用协议。判断能否导入首先要读取二维码内容即使看到otpauth://还要继续核对类型、密钥、算法、位数和周期。一个典型的 URIotpauth://totp/Example:aliceexample.com?secretBASE32SECRETissuerExamplealgorithmSHA1digits6period30可拆成以下字段字段含义常见问题totp基于时间的一次性密码若为hotp则是计数器模式不能按 TOTP 处理Label条目显示标签常含服务名和账号标签不参与验证码计算但重复命名会增加误用风险secretBase32 表示的共享密钥缺失、截断或多余字符都会导致结果不同issuer发行方/服务名主要用于识别应与标签保持清楚一致algorithmHMAC 哈希算法常见 SHA-1、SHA-256、SHA-512双方必须一致digits输出位数常见 6 位或 8 位period时间步长常见 30 秒也可能不同为什么“能扫进去”仍不代表兼容有些验证器会接受二维码却忽略未支持的参数或回落到默认值。例如目标平台按 SHA-512 计算而验证器固定使用 SHA-1界面仍可能生成六位数但平台不会接受。因此兼容性至少有三层格式兼容能识别 URI参数兼容算法、位数、周期和密钥解析一致业务兼容平台绑定和后续登录均成功。缺少第三层真实验证不能把产品列入“已支持平台”。不要直接展示生产密钥读取二维码参数时优先在测试账号和隔离环境中进行。不要把生产二维码上传到在线解码网站也不要把完整secret放进工单、聊天记录、截图或文章。如果需要留存测试证据可以记录Scheme: otpauth Type: totp Algorithm: SHA512 Digits: 6 Period: 30 Secret: 已脱敏仅记录长度与格式是否有效密钥只要被第三方复制就可能在同一时间生成有效验证码。二维码本身应按认证凭据处理而不是普通图片。验收一个验证器的正确步骤第一步确认平台入口在平台官方安全设置中选择“Authenticator App”“验证器应用”或明确的 TOTP 入口。若页面要求安装平台专用 App不能自行替换成通用验证器。第二步核对参数读取测试二维码或手动配置说明记录算法、位数、周期。平台没有公开参数时以测试账号实测为准不能靠六位码外观猜测。第三步连续核对两个周期完成绑定后至少等待一次验证码变化并验证下一周期仍能通过。这样可以减少偶然踩中时间窗口造成的误判。第四步完成真实登录退出测试账号后重新登录并确认恢复码或备用方式已保存。只在绑定页面提交成功还不等于完整登录链路可用。第五步记录环境记录测试日期、账户类型、地区、客户端版本和平台入口。平台可能按地区、套餐或组织策略提供不同选项。参数用于排查结果要靠完整登录验证读取 URI 参数可以帮助定位问题但不能只凭参数表判断兼容。更可靠的验收顺序是验证器能够添加条目、平台接受当前动态码、退出后能够重新登录并且恢复码已经保存。参数和实测结果不一致时优先保留测试记录再继续排查二维码内容、设备时间和平台策略。最小测试记录- 平台与账户类型 - 测试日期 - 官方设置入口 - URI 类型 - Algorithm - Digits - Period - 是否成功导入 - 连续两个周期是否通过 - 是否完成重新登录 - 恢复方式是否保存 - 结论待确认 / 条件支持 / 已通过判断二维码时先问“它编码了什么”再问“双方是否按同一组参数计算”。这比看到六位码后直接下结论可靠得多。用 Free2FA 做一次 URI 验收理解otpauth最好的方式不是把二维码上传到解析网站而是完成一次安全的真实验收。可以使用「二次验证码 Free2FA」从 GitHub、OpenAI 或 Google Account 官方安全设置获取二维码完成添加后观察两个周期再退出账号重新登录。二维码、手动密钥和动态码都不要放进截图、日志或在线工具。Free2FA 能添加条目只是第一步平台接受验证码并成功登录才是兼容结论。