扫描 Singpass 二维码后，系统里发生了什么

Tue, 21 Jul 2026 08:29:11 +0800

你在笔记本电脑上打开一家银行的网站。

点击“使用 Singpass 登录”。

页面上出现一个二维码。

你打开 Singpass 应用，扫描二维码，核对服务名称，然后确认登录。网站随即知道可以让你登录了。

在用户眼里，整个过程简单得近乎不可思议：网页显示二维码，手机完成确认，浏览器接着登录。

但真正关键的问题是：

这个二维码究竟证明了什么？

答案不是“二维码里装着我的身份信息”。

设计得当的二维码登录，恰恰不该如此。二维码里不应包含你的 NRIC、姓名或个人资料，也不应放入长期有效的登录令牌。它只应是一份短期有效的邀请，请你完成一笔特定的身份验证事务。

用系统设计的语言来说：

二维码登录，不是把身份装进二维码。
它发起的是一项短期有效的挑战，
由可信的移动端凭据批准，
再交给网页端的登录会话使用。

这正是整个设计的核心。

这就是大家熟悉的表面体验：扫描或轻点二维码，就能登录。真正重要的是，这个二维码被允许代表什么、它会多快过期，以及手机上的批准最终会绑定到哪个浏览器会话。

二维码只是一道入口链接到标题

第一个常见误区，是把二维码本身当成秘密。

人们很容易以为，二维码携带着某种神奇的身份数据。毕竟，用户一扫码，浏览器就登录成功了。但如果仅凭二维码就能登录，那么任何看到它的人都可以复制、转发，甚至反复使用。

这样的设计非常危险。

更稳妥的做法，是让二维码只包含一个不透明的挑战标识：

qr_challenge_id = "看似随机、短期有效的标识符"

这个标识符本身没有多少意义。它指向服务器端的一条状态记录，而这条记录是在浏览器发起登录请求时创建的。

服务器掌握的信息包括：

二维码只是让移动应用向系统表明：

我正在回应这一次特定的登录尝试。

因此，二维码登录不能只做“生成二维码”这一步，后台还必须维护一个生命周期很短的状态机。

屏幕上的流程看似简单，底层却更接近这样：

已创建 -> 已扫描 -> 已批准 -> 已使用
 \-> 已过期
 \-> 已拒绝
 \-> 已取消

状态机之所以重要，是因为登录不是一个静止的页面，而是一笔横跨两台设备的交互事务。系统必须拒绝不安全的状态变化，例如：

已过期 -> 已批准
已使用 -> 已批准
已批准 -> 再次批准

重试、网络延迟或重复点击，都可能触发两次批准请求。但系统不应因此建立两个浏览器会话，也不应签发两个授权码。只有第一次有效批准可以生效。