メインコンテンツへスキップ

DID Connectワークフロー

DID Connectセッションは、ユーザーがDID Walletを使用して分散型アプリケーション（DApp）と対話することを可能にする、安全で分散型の認証プロセスです。このガイドでは、最初のQRコードスキャンからユーザーの応答の最終的な処理まで、エンドツーエンドのプロセスを解説します。

典型的なワークフローには、主に4つの登場人物が関わります：

  1. ユーザー

    アプリケーションを操作する個人。

  2. ブラウザ（DAppフロントエンド）

    ユーザーのブラウザで実行されるアプリケーションのユーザーインターフェース。

  3. DAppバックエンド

    @arcblock/did-connect-jsライブラリが統合されているサーバーサイドアプリケーション。

  4. DID Wallet

    ユーザーの分散型ID（DID）と秘密鍵を管理する、モバイルまたはウェブベースのウォレット。

ビジュアル概要

以下の図は、典型的な認証セッション中のDAppとDID Wallet間の高レベルなやり取りを示しています。

DAppとDID Wallet間の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 WalletでQRコードをスキャンします。

  2. クレームのリクエスト

    ウォレットはQRコードから取得した認証URLにGETリクエストを送信します。これにより、バックエンドのonAuthRequestハンドラが呼び出されます。

  3. バックエンドの応答

    バックエンドはセッションのステータスをscannedに更新し、署名済みのJSON Web Token（JWT）を返します。このJWTには、アプリケーションがユーザーに要求している情報、すなわちクレーム（例: 接続を要求するauthPrincipal、ユーザーデータを要求するprofile）が含まれています。

  4. ユーザーの承認

    ウォレットはJWTを検証し、リクエストをユーザーに提示します。ユーザーはリクエストを承認するか拒否するかを選択できます。

3. 応答の処理

  1. ウォレットの送信: ユーザーが承認すると、ウォレットは要求された情報を含む独自のJWTを作成し、署名します。そして、そのJWTを同じ認証URLにPOSTします。
  2. バックエンドの検証: このリクエストはバックエンドのonAuthResponse関数によって処理されます。ライブラリはウォレットの署名とチャレンジを自動的に検証します。これはセキュリティ上、最も重要なステップです。
  3. ビジネスロジックの実行: 検証が成功すると、ライブラリはonAuthコールバックをトリガーします。ここに、次のようなコアビジネスロジックを配置します：
  • ユーザーのuserDidに基づいてユーザーアカウントを検索または作成する。
  • claimsデータを処理する（例: ユーザーのプロファイルを保存する）。
  • ブラウザ用のウェブセッショントークンを生成する。
  • updateSessionを使用して、フロントエンドが後で取得できるデータを保存する。
  1. セッションの完了: バックエンドはセッションのステータスをsucceedにマークします。

4. フロントエンドの更新

ユーザーがウォレットを操作している間、DAppのフロントエンドはステータスエンドポイント（例: GET /api/did/login/status?_t_={token}）をポーリングします。ステータスがsucceedに変わると、プロセスが完了したことがわかります。その後、セッションから必要なデータ（ログイン情報など）を取得し、ユーザーをダッシュボードにリダイレクトするなど、UIを適宜更新できます。

この一連のフローは、ユーザーが自身のデータを管理できる、安全なパスワードレス認証体験を提供します。

ウォレットから受信したデータの管理方法をより深く理解するには、ウォレットの応答の処理のガイドに進んでください。