二维码登录方法与认证

安全便捷的认证方法比以往任何时候都更加重要。随着我们每天在不同设备上访问的在线服务越来越多，传统的密码系统正变得效率低下且日益繁琐。特别是对于那些在原生应用（iOS 或 Android 应用）上拥有大量用户的公司而言，这导致了对基于二维码登录的需求日益增长。这种方式提供了一种快速简便的用户认证方法，无需输入复杂的密码甚至用户名。

在这种背景下，出现了以下问题：

• 使用原生应用的二维码认证是如何工作的？
• 与使用 Passkeys 的二维码认证相比，它有何不同？

Native QR Code Revolut

Passkeys QR Code Apple

在原生应用登录中使用二维码的著名例子包括 WhatsApp、TikTok 或 Revolut 等“应用优先”的服务。与此同时，支持 Passkeys 登录的公司名单也在迅速增长。

在本文中，我们将探讨基于二维码的认证技术。我们不会重点讨论用于第二因素初始化的 TOTP 二维码（需要配合 Authy 或 Google Authenticator 等额外应用）。

我们还将比较不同的二维码认证方法，审视它们的优缺点以及潜在的漏洞。

读完本文，您将更清楚地了解基于二维码的认证是否是满足您安全需求的正确选择。

二维码（QR code），即快速响应码，是一种可以存储从 URL 到纯文本等各种信息的二维条码。二维码最初由丰田集团的子公司 Denso Wave 于 1994 年开发，旨在快速高效地追踪汽车零部件。从那时起，二维码不断发展，并因其能在小小的可扫描方块中存储大量数据而应用于各行各业。

“QR Code”一词实际上是 Denso Wave 的商标，尽管该技术本身已被广泛采用，并不受该商标的限制。二维码的特点是其黑白相间的方形图案，可以使用智能手机或专用扫描设备（二维码扫描器）进行扫描，以访问编码信息。

多年来，对二维码的支持已被集成到 iOS 和 Android 等移动操作系统中。这两个平台都通过各自的相机应用原生支持二维码扫描，使用户无需额外软件即可轻松与二维码互动。

Subscribe to our Passkeys Substack for the latest news.

Subscribe

通常，与应用结合使用的二维码会利用自定义 URL 或应用链接。这些链接可以触发应用自动打开，如果设备上安装了相应的应用。如果应用未安装，二维码可以将用户引导至相关的应用商店下载并安装该应用，从而提供流畅的用户体验。在这里，您可以看到 Revolut 为应用处理注册的路径列表：

https://revolut.com/.well-known/apple-app-site-association
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "QUZEZSEARC.com.revolut.revolut",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.test",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.retail.india",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.retail.india-debug",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.invest",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.invest-debug",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.revolutx",
                "paths": ["/app/*"]
            },
            {
                "appID": "QUZEZSEARC.com.revolut.revolutx-debug",
                "paths": ["/app/*"]
            }
        ]
    }
}

如您所见，所有以“/app/*”开头的链接都会被处理，您将在下一节中看到一个例子。通过在二维码中嵌入自定义 URL 和应用链接，企业和开发者可以创建定制化体验，将用户直接引导至目标应用或服务，从而在用户互动中提升便利性和安全性。

通过原生应用进行二维码登录利用了移动设备摄像头与二维码中嵌入的特定 URL 之间的无缝交互。该过程通常从用户使用智能手机的摄像头扫描网站或另一台设备上显示的二维码开始。该二维码包含一个自定义 URL，专门设计用于与特定的原生应用（例如 iOS 或 Android 设备上的应用）进行交互。

例如，像 Revolut 这样的服务可能会使用一个带有 URL 的二维码，如 https://revolut.com/app/challenges/qr/e2d78521-d38a-4773-b1b8-27a902a36b4b。这个 URL 注定会被用户设备上安装的 Revolut 应用识别。

当扫描二维码时，应用会自动捕获此链接，识别它并显示相应的应用（在上面的例子中，您可以看到“Revolut”被识别为匹配的应用），然后继续在内部处理登录过程。这种交互是通过 iOS 和 Android 都支持的深度链接机制实现的，该机制允许特定链接直接在已安装的应用内打开，而不是在网页浏览器中打开：

如果设备上未安装该应用，操作系统通常会提示用户安装该应用，将他们重定向到相应的应用商店，无论是 iOS 设备的 Apple App Store 还是 Android 设备的 Google Play Store。

这确保了即使用户最初没有安装该应用，他们也可以快速轻松地获取它，并在安装后继续该过程。

在大多数情况下，已经安装了该应用的现有客户将体验到顺畅的登录过程。他们扫描二维码，应用自动打开，认证完成，无需输入用户名或密码。这种方法主要为用户提供了便利，因为在二维码扫描过程中没有传输敏感信息。

技术上发生的是，手机上现有的已登录会话被用来认证桌面上的新会话。有不同的技术可以实现这一点。一个非常精细的版本发布在 WhatsApp 安全白皮书的“客户端注册 → 配套设备注册 → 使用二维码链接”部分。

图片来源 https://engineering.fb.com/2021/07/14/security/whatsapp-multi-device/

由于 WhatsApp 自 2021 年起支持多设备访问和端到端加密，其架构并不完全适用于认证——因为该协议主要是为多设备消息应用设计的。有更简单的方法可以实现安全握手，具体取决于实际的认证实现。需要记住的是，您始终需要确保用户会话和设备与服务器之间通信渠道的安全处理。无论二维码认证登录的实现有多复杂，都应始终遵循一些关键的安全原则：

1. 会话完整性：用于在桌面或其他设备上认证新会话的手机上现有已登录会话必须经过安全验证。这通常涉及使用安全令牌或其他加密方法检查会话的真实性，以防止会话劫持或重放攻击。
2. 加密通信：移动应用、服务器和请求认证的设备之间的所有通信都应使用 HTTPS 加密。这有助于确保敏感信息，包括会话令牌和登录详细信息，在传输过程中不会被拦截或篡改。
3. 安全的令牌生成：为二维码认证过程生成的任何令牌或凭据都应安全生成。这可以包括将其固定到请求设备上，以防止其在其他设备上被用作预防措施（例如，浏览器代理）。
4. 用户验证登录：在完成认证过程之前，建议增加一个步骤，让用户可以验证或确认登录尝试。这可以是在移动设备上显示一条需要用户批准并显示认证详情的通知，从而增加一层额外的安全性（如上图所示）。
5. 基于时间的限制：对二维码的有效性实施基于时间的限制，以最大限度地降低二维码落入坏人之手被用于未经授权访问的风险。限制二维码可使用的时间窗口有助于减少潜在的安全威胁。它应该自动刷新，并且最大有效期应低于 120 秒，以避免中间人攻击。
6. 基于位置的限制：还应强制执行与登录尝试相关的限制，例如“不可能的旅行”检测。这可能涉及根据可疑的基于 IP 的情报自动拦截登录尝试，例如在美国生成二维码，而在欧洲打开应用进行认证。
7. 速率限制、日志记录和监控：实施适当的速率限制、日志记录和监控，以检测和响应与二维码登录相关的任何可疑活动。这有助于识别潜在的安全漏洞并及时采取行动保护用户帐户。
8. 用户通知：在新设备上成功登录应向用户发送一封电子邮件通知，其中包含重要信息（例如登录尝试的时间、地点、设备和 IP 地址）以及如果登录不是由用户触发时该怎么做的说明（例如立即联系服务、监控帐户或移除所有已登录设备，如果系统支持的话）。

通过遵循这些最佳实践，公司可以实施既用户友好又安全的基于二维码的认证，利用移动设备的便利性，同时保持强大的安全措施来保护用户数据和会话。

Become part of our Passkeys Community for updates & support.

Join

现在让我们来看看通过 Passkeys 进行的二维码登录。

基于 Passkeys 的认证提供了一个安全的跨设备认证系统，该系统已集成到 iOS 和 Android 生态系统中，并在 WebAuthn 标准中进行了规定。目前，只有在 iOS 或 Android 上创建的 Passkeys 可用于通过二维码进行跨设备认证（CDA）。

让我们来分析一下使用 Passkeys 的二维码登录是如何工作的。下图展示了不同步骤的高级概览。

对于 iOS 和 Android，Passkeys 都存储在平台的原生认证器中（例如 Face ID、Touch ID 或 Android 生物识别）。这确保了用户的 Passkeys 在他们登录了相同 Apple ID（对于 iOS）或 Google 帐户（对于 Android）的所有现代操作系统版本的设备上都可用。

• 两台设备都需要有效的互联网连接：参与认证过程的两台设备都必须有有效的互联网连接。这对于在认证过程中同步数据和验证凭据至关重要。
• 两台设备都需要支持蓝牙：两台设备都需要支持蓝牙，并且蓝牙必须被激活。蓝牙用于在设备之间建立邻近关系，确保设备在认证期间彼此靠近，从而降低来自远程位置的钓鱼风险。

• 设备绑定的桌面 Passkeys：设备绑定且位于桌面上的 Passkeys，例如在 Windows 平台上的 Passkeys，不符合基于二维码的 CDA 的条件。
• 对蓝牙的依赖： 依赖蓝牙有时可能是一个缺点，因为潜在的连接问题或设备设置可能会干扰蓝牙邻近检查。虽然建立邻近关系可以增强安全性，但如果设备无法通过蓝牙连接，也可能导致可用性挑战。然而，一旦设备成功配对，后续的连接通常会变得更加直接。

Discuss passkeys news and questions in r/passkey.

Join Subreddit

• 无远程钓鱼攻击： 使用蓝牙进行邻近检查可确保两台设备在认证过程中物理上彼此靠近，从而降低了来自远程位置的钓鱼攻击风险。
• 同步的 Passkeys 提供更好的用户体验： Passkeys 在设备间的同步也提供了无缝的用户体验，因为用户不需要管理多套凭据。

在实施基于 Passkeys 的跨设备认证（CDA）时，向用户提供关于该过程的明确指导至关重要。应告知用户将显示一个二维码，并且他们需要使用手机扫描它。

我们认为，重要的是要确保在用户没有可用于 CDA 的 Passkey 时不显示二维码。此外，有必要在显示二维码之前验证用户当前的操作系统和浏览器是否支持 CDA。

Want to find out how many people use passkeys?

View Adoption Data

为了有效管理这些情况，我们在这篇文章中概述了所有关键案例，因此我们在这里不作详细介绍。我们的 Passkey 智能系统旨在自动处理这些情况，确保仅在适当的时候显示二维码，并引导用户顺利完成认证过程。这确保了在各种设备和操作系统上保持高安全性和兼容性的同时，提供无缝的体验。

在本节中，我们将总结本文讨论的两种主要的基于二维码的登录方法：通过原生应用进行二维码登录和通过 Passkeys 进行二维码登录。每种方法都有其独特的优势，并根据安全性、用户体验和实现复杂性等因素适用于不同的用例。

• 通过原生应用进行二维码登录利用深度链接将二维码与移动设备上安装的特定应用连接起来。当用户扫描二维码时，相关应用被触发，从而实现无缝且安全的登录过程。这种方法常用于像 WhatsApp、TikTok 和 Revolut 这样的“应用优先”的应用中，用户熟悉应用环境，可以轻松进行认证而无需输入密码。
• 通过 Passkeys 进行二维码登录采用了一种更先进的跨设备认证方法，直接与操作系统的平台认证器集成（无需安装任何原生应用）。这种方法旨在提供高水平的安全性，使用同步的 Passkeys，并要求两台设备在认证过程中保持近距离（通过蓝牙验证）。这种方法能有效防范钓鱼攻击，并在多个设备上提供简化的用户体验。

让我们看看这两种方法的比较以及它们的不同特点：

比较表：通过原生应用进行二维码登录 vs. 通过 Passkeys 进行二维码登录

我们在比较表中侧重于基于认证的特性，第三节中概述的相关要求适用于这两种方案。使用 Passkeys 时不需要基于位置和时间的限制，因为它们通过 WebAuthn 采用了防钓鱼和邻近检查机制。

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

正如引言中所述，我们已经探讨了两种最常见的跨设备认证场景，让我们简要总结一下：

• 通过原生应用进行二维码登录非常适合那些在其原生应用上拥有强大用户基础、尚未考虑实施 Passkeys 且不太担心钓鱼攻击的公司。这种方法通过使用应用现有的认证机制提供了便利性和安全性，减少了频繁使用该应用用户的摩擦，但对于不常登录应用的情况没有帮助。
• 通过 Passkeys 进行二维码登录提供了一个更安全、更灵活的选择，特别是在需要跨设备认证且正在考虑或已经使用 Passkeys 作为认证因素的环境中。通过利用平台级认证和基于蓝牙的邻近检查，这种方法将唯一面向未来的防钓鱼多因素认证方法也带到了跨设备场景中。

回答我们引言中的问题：

• 这两种方法有何不同： 每个组织都应选择最适合其需求的方法，考虑用户基础、安全要求和期望的用户体验等因素。对于以应用为中心的服务，集成通过原生应用的二维码登录可能就足够了。然而，对于那些优先考虑最高安全性、跨设备能力的公司来说，通过 Passkeys 进行二维码登录则提供了一个强大的解决方案。

无论当前对哪种解决方案更适合现有认证架构的评估如何，都应记住，Passkeys 是对未来认证方式的一项投资，因为整个生态系统正朝着这个方向明确发展。尽早开始收集 Passkeys 可以与不同的CDA 策略相结合。