跳到主要內容

DID Connect 工作流程

DID Connect 會話是一個安全、去中心化的身份驗證過程，允許使用者使用其 DID 錢包與去中心化應用程式 (DApp) 互動。本指南將詳細解析從最初的 QR 碼掃描到最終處理使用者回應的端到端流程。

典型的工作流程涉及四個主要參與者：

  1. 使用者

    與應用程式互動的個人。

  2. 瀏覽器 (DApp 前端)

    在使用者瀏覽器中執行的應用程式使用者介面。

  3. DApp 後端

    已整合 @arcblock/did-connect-js 函式庫的伺服器端應用程式。

  4. DID 錢包

    使用者用於管理其去中心化身份 (DID) 和私鑰的行動或網頁錢包。

視覺化概覽

下圖說明了在典型的身份驗證會話中，DApp 和 DID 錢包之間的高層級互動。

一張圖表，顯示了 DApp 和 DID 錢包之間的 DID Connect 工作流程。

逐步解析

讓我們深入探討流程中每個步驟的技術細節。下面的序列圖顯示了完整的通訊流程。

The DID Connect Workflow

1. 會話啟動：產生 QR 碼

當使用者想要登入或執行受保護的操作時，流程即開始。

  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 渲染成 QR 碼供使用者掃描。

2. 錢包互動：掃描與批准

  1. 掃描

    使用者使用其 DID 錢包掃描 QR 碼。

  2. 請求聲明

    錢包向 QR 碼中的 auth URL 發出 GET 請求。這會觸發後端上的 onAuthRequest 處理器。

  3. 後端回應

    後端將會話狀態更新為 scanned，並傳回一個已簽署的 JSON Web Token (JWT)。此 JWT 包含您的應用程式向使用者請求的資訊，稱為聲明（claims）（例如，authPrincipal 用於請求連接，或 profile 用於請求使用者資料）。

  4. 使用者批准

    錢包驗證 JWT 並向使用者呈現請求。使用者可以選擇批准或拒絕該請求。

3. 處理回應

  1. 錢包提交：如果使用者批准，錢包會建立並簽署自己的 JWT，其中包含所請求的資訊。然後它會將此 JWT POST 回同一個 auth URL。
  2. 後端驗證：此請求由後端的 onAuthResponse 函數處理。函式庫會自動驗證錢包的簽名和挑戰碼。這是最關鍵的安全步驟。
  3. 執行業務邏輯：如果驗證成功，函式庫會觸發您的 onAuth 回呼。這是您放置核心業務邏輯的地方，例如：
  • 根據使用者的 userDid 查找或建立使用者帳戶。
  • 處理 claims 資料（例如，儲存使用者的個人資料）。
  • 為瀏覽器產生一個 Web 會話 token。
  • 使用 updateSession 儲存前端稍後可以檢索的資料。
  1. 會話完成：後端將會話狀態標記為 succeed。

4. 更新前端

當使用者與其錢包互動時，您的 DApp 前端會輪詢一個狀態端點（例如，GET /api/did/login/status?_t_={token}）。一旦看到狀態變為 succeed，它就知道流程已完成。然後，它可以從會話中獲取任何必要的資料（如登入 token）並相應地更新 UI，例如，將使用者重新導向到他們的儀表板。

這整個流程提供了一種安全的、無密碼的身份驗證體驗，讓使用者能夠掌控自己的資料。

要更深入地了解如何管理從錢包收到的資料，請繼續閱讀我們的指南 處理錢包回應。