跳到主要内容

DID Connect 工作流

DID Connect 会话是一个安全的、去中心化的身份验证过程，允许用户使用其 DID 钱包与去中心化应用（DApp）进行交互。本指南将端到端地分解整个过程，从最初的二维码扫描到最终处理用户的响应。

典型的工作流涉及四个主要参与者：

  1. 用户

    与应用程序交互的个人。

  2. 浏览器（DApp 前端）

    在用户浏览器中运行的应用程序的用户界面。

  3. DApp 后端

    集成了 @arcblock/did-connect-js 库的服务器端应用程序。

  4. DID 钱包

    用户的移动或网页版钱包，用于管理其去中心化身份（DID）和私钥。

可视化概览

下图说明了在典型的身份验证会话中，DApp 和 DID 钱包之间的高层交互。

一张展示 DApp 和 DID 钱包之间 DID Connect 工作流的图表。

分步详解

让我们深入探讨该过程中每个步骤的技术细节。下面的序列图展示了完整的通信流程。

The DID Connect Workflow

1. 会话启动：生成二维码

当用户想要登录或执行受保护的操作时，该过程开始。

  1. 前端请求：DApp 的前端向其后端的一个专用端点发出请求（例如 GET /api/did/login/token）。
  2. 后端处理器：您后端上的 did-connect-js 处理器（generateSession）会创建一个新的、唯一的会话。它会生成：
  • 一个唯一的 token 来识别会话。
  • 一个加密的 challenge 以防止重放攻击。
  • 一个包含这些信息的完整 DID Connect URL（例如 https://didconnect.io/i/?url=...）。
  1. 前端显示：后端将 token 和 url 返回给前端。然后，前端将 url 渲染成一个二维码供用户扫描。

2. 钱包交互：扫描与批准

  1. 扫描

    用户使用其 DID 钱包扫描二维码。

  2. 请求声明

    钱包向二维码中的认证 URL 发出 GET 请求。这会触发您后端上的 onAuthRequest 处理器。

  3. 后端响应

    您的后端将该会话状态更新为 scanned，并返回一个已签名的 JSON Web Token (JWT)。此 JWT 包含您的应用程序向用户请求的信息，称为声明（例如，authPrincipal 用于请求连接，或 profile 用于请求用户数据）。

  4. 用户批准

    钱包验证该 JWT 并向用户呈现请求。然后用户可以选择批准或拒绝该请求。

3. 处理响应

  1. 钱包提交：如果用户批准，钱包会创建并签署自己的包含所请求信息的 JWT。然后它将此 JWT POST 回到同一个认证 URL。
  2. 后端验证：此请求由您后端中的 onAuthResponse 函数处理。该库会自动验证钱包的签名和挑战码。这是最关键的安全步骤。
  3. 执行业务逻辑：如果验证成功，该库会触发您的 onAuth 回调。您应在此处放置核心业务逻辑，例如：
  • 根据用户的 userDid 查找或创建用户帐户。
  • 处理 claims 数据（例如，保存用户的个人资料）。
  • 为浏览器生成一个 Web 会话令牌。
  • 使用 updateSession 存储前端稍后可以检索的数据。
  1. 会话完成：后端将会话状态标记为 succeed。

4. 更新前端

在用户与其钱包交互的同时，您的 DApp 前端会轮询一个状态端点（例如 GET /api/did/login/status?_t_={token}）。一旦看到状态变为 succeed，它就知道该过程已完成。然后，它可以从会话中获取任何必要的数据（如登录令牌）并相应地更新 UI，例如，将用户重定向到他们的仪表盘。

这整个流程提供了一种安全的、无密码的身份验证体验，让用户能够掌控自己的数据。

要更深入地了解如何管理从钱包收到的数据，请继续阅读我们的指南 处理钱包响应。