メインコンテンツへスキップ
Didit は、委任型の本人確認のために設計されたOpenID Connect認可サーバーを提供しています。 このサーバーは、Oktaの「bring your own identity verification vendor」(BYO IDV)フレームワークが求める仕様を実装しています。具体的には、Pushed Authorization Requests(PAR、RFC 9126)、PKCEを用いた認可コードフロー、そしてOpenID Connectのverified_claimsオブジェクトを含むIDトークンです。 このプロファイルに対応するリライングパーティであれば、Auth0のpost-loginアクションを含め、同じエンドポイントを利用できます。

エンドポイント

すべてのエンドポイントは、本人確認ブリッジのベースURLの配下にあります。 本番環境とサンドボックスは同じエンドポイントを使用します。 環境は、クライアント認証情報に紐づくアプリケーションによって決まります。 環境ごとに別々のクライアント認証情報を使用し、対応するアプリケーションに属するワークフローを使用してください。 検証結果のシミュレーションについては、サンドボックスとテストデータを参照してください。 {base}/.well-known/openid-configurationのディスカバリードキュメントには、これらすべてが記載されています。 クライアント認証にはclient_secret_basicまたはclient_secret_postを使用します。 認可コードフローでは、code_challenge_method=S256によるPKCEが必須です。 IDトークンはRS256で署名されています。JWKSエンドポイントを使って検証してください。

フロー

  1. リライングパーティは、PKCEチャレンジ、state、nonce、登録済みのredirect_uri、スコープopenid profile identity_assurance、および検証したいクレームを含めて、認可リクエストをPOST /parにプッシュします。 Didit は、60秒間有効な使い捨てのrequest_uriを返します。
  2. リライングパーティは、ユーザーのブラウザをGET /authorize?request_uri=...にリダイレクトします。 Didit は検証セッションを作成し、ユーザーをホスト型の検証フローに送ります。
  3. ユーザーが検証を完了すると、Didit は検証の判定を行い、抽出した本人情報をプッシュされたクレームと照合したうえで、ワンタイムのcodeと元のstateを付けて、ユーザーをリライングパーティのredirect_uriに戻します。
  4. リライングパーティは、code_verifierを使ってPOST /tokenでコードを交換し、署名済みのIDトークンを受け取ります。

クレームのリクエスト

照合するクレームは、PARリクエストの標準のOpenID Connect claimsパラメーター内で送信します。 given_nameとfamily_nameの両方に対応しており、どちらも常にあいまい照合されます。 verified_claimsは配列であり、OktaのBYO IDVプロファイルおよび後述のIDトークンのレスポンスに準拠しています。

IDトークン

IDトークンにはverified_claims配列が含まれます。assurance_levelがVERIFIEDになるのは、検証セッションが承認済みかつリクエストしたすべてのクレームが検証済みの書類と一致した場合のみです。 それ以外の場合はFAILEDになります。
verification_processはDiditのセッションIDです。これを使って、コンソールまたはセッションAPIで検証を確認できます。
ユーザーを検証済みとして扱うのは、trust_frameworkがIDV-DELEGATEDかつassurance_levelがVERIFIEDの場合のみにしてください。 それ以外の組み合わせは、検証が成功しなかったことを意味します。

Oktaの設定

本番環境とサンドボックスのアプリケーションで本人確認を有効にし、それぞれを本人確認ワークフローに紐づけ、各Oktaテナントの正確なコールバックURLを登録するよう、Diditに依頼してください。 既存のアプリケーションやAPIキーだけでは、この連携は有効になりません。 Okta Admin Consoleで、カスタムの本人確認ベンダーを追加し、以下の値を入力します。 Oktaは、この連携をタイプIDV_STANDARD、プロトコルID_PROOFINGのアイデンティティプロバイダーとして作成します。その後、Account Management Policyのルールからこれを参照します。 本番環境とサンドボックスは、それぞれの認証情報を使って別々の本人確認連携として設定してください。 どちらにも上記のエンドポイントを使用します。 このフローではPKCEも使用しますが、クライアントシークレットは必須です。 この連携では、別途作成した名前付きのAPIキーをアプリケーションのプライマリAPIキーの代わりに使用することはできません。 クライアントに登録できるよう、コールバックURLをDiditに伝えてください。 Oktaはこれを{yourOktaOrgUrl}/idp/identity-verification/callbackとして生成します。

Auth0の設定

Auth0にはネイティブのIDVベンダー枠がないため、検証は、ユーザーを同じフローにリダイレクトするpost-loginアクションから実行されます。 DIDIT_IDV_BASE、DIDIT_CLIENT_ID、DIDIT_CLIENT_SECRETをアクションのシークレットとして保存し、https://{yourAuth0Domain}/continueをリダイレクトURIとしてDiditに登録してください。
Auth0は、ログインを再開できるよう、/authorizeへのリダイレクトに独自のstateを付加します。Diditはそのstateを採用して/continueにそのまま返します。これにより、Auth0はログインを完了できます。Auth0のstateをPARのボディに含める必要はありません(リダイレクトの時点まで生成されないためです)。
PKCEのcode_verifierは、単一のapp_metadataフィールドではなく、ログイントランザクションごとに(event.transaction.idをキーとして)保存してください。 ユーザーが再試行したり、ログインを重複して実行したりすると、共有の単一フィールドが上書きされ、トークン交換がinvalid_grantで失敗します。

エラー

エラーはRFC 6749およびRFC 9126に準拠します。 クライアント認証に失敗した場合は401と{"error": "invalid_client"}が返されます。期限切れまたは再利用されたrequest_uriや認可コードの場合は、400とinvalid_requestまたはinvalid_grantが返されます。 認可コード、request_uriの値、検証セッションはいずれも1回限り使用できます。
最終更新日 2026年11月1日