エンドユーザー認証：サインイン、パスキー、セッション管理

Authenticationは、お客様の顧客をお客様のアプリケーションにサインインさせる機能です。Diditコンソールへのサインインや、Didit開発者アカウントの作成とは別のものです。また、人物の本人確認とも別のものです。 Authenticationは単独で使うことも、本人確認やトランザクションモニタリングと組み合わせて使うこともできます。サインインによって本人確認が承認されたり、支払いが許可されたりすることはありません。これらの判定は、お客様のバックエンドが各プロダクトの結果に基づいて行います。

​

仕組み

各アプリケーションには、専用のサインインオリジンと専用のトークン発行者が割り当てられます。本番環境のアプリケーションとサンドボックスのアプリケーションは別々であり、オリジン、設定、アイデンティティもそれぞれ独立しています。 フローはPKCE付きのOAuth 2.0認可コードフローです(S256のみ):

1. お客様のアプリがredirect_uri、state、code_challenge、code_challenge_method=S256を付けて{origin}/sign-inを開きます。
2. ホスト型ページが、お客様が有効にした方法で、必要な第2要素も含めて、ユーザーをサインインまたはサインアップさせます。
3. ブラウザがcodeとstateを付けてお客様のredirect_uriに戻ります。
4. お客様のアプリがPOST {origin}/token/でコードを交換し、アクセストークン、IDトークン、リフレッシュトークンを取得します。

トークンの仕様についてはトークンとJWKSを、各方法についてはサインイン方法をご覧ください。

​

プラットフォームを選択する

​

アプリケーションを準備する

1. お客様のアプリケーションでAuthenticationを有効にするようDiditに依頼してください。まずサンドボックスのアプリケーションでテストしてください。
2. 正確なリダイレクトURL(最大50件)と、ランタイムAPIを呼び出すブラウザのallowed_origins(最大50件)を登録します。
3. 提供したいサインイン方法を有効にします。Didit ID Walletは常に有効です。
4. セッションとパスワードの設定を選択します(下記参照)。
5. 本番運用を開始する前に、サインアップ、サインイン、パスワードの再設定、MFA、セッションの有効期限切れ、ログアウトをテストしてください。

パスキーはそのオリジンに紐づきます。後からカスタムドメインを有効化した場合、ユーザーはパスキーを再登録する必要があります。

​

リダイレクトURL

Diditは、お客様が登録したアドレスにのみユーザーを戻します。 コンソールのAuthentication > Security and sessions > Redirect URLs and allowed originsで登録してください。 サインインリクエストのredirect_uriは、スキーム、ホスト、ポート、パス、クエリのすべてにおいて、登録済みのURLと1文字ずつ一致している必要があります。 ポートが異なる場合、末尾にスラッシュがある場合、大文字と小文字が異なる場合は、別のアドレスとして扱われます。 ワイルドカード、フラグメント、URL内の認証情報、カスタムスキームは拒否されます。 アドレスが登録されていない場合、Diditがそのアドレスにリダイレクトすることは決してありません。 {origin}/sign-inは、何をどこに登録すべきかを示すページとともに400を返し、POST {origin}/authorize/は400 {"error": "invalid_redirect_uri"}を返します。

​

ローカル開発

サンドボックスのアプリケーションを使って、ご自身のマシンでテストします:

1. コールバックをポート付きで登録します。例: http://localhost:3000/auth/callback。
2. ブラウザのコードがランタイムAPIを呼び出す場合、たとえばPOST {origin}/token/でコードを交換する場合は、そのオリジンもAllowed originsに追加します。パスや末尾のスラッシュを付けずにhttp://localhost:3000と指定してください。
3. pk_test_...キーを使って、サンドボックスのオリジンhttps://<slug>.sandbox.auth.didit.meでサインインを開始します。

localhost、127.0.0.1、[::1]はそれぞれ別のアドレスであり、ポートごとにも別のアドレスとして扱われます。 使用するものをそれぞれ登録してください。 本番環境のアプリケーションはhttp://を一切受け付けません。 本番運用を開始する前に、本番環境のhttps://コールバックを本番環境のアプリケーションに登録してください。

​

アプリケーション設定

これらの設定は、コンソールで管理するか、write:authenticationを持つ承認済みのコンソールセッションで管理します。

​

製品をまたいで同じ人物として扱う

すべてのアイデンティティはvendor_dataの値を持ちます。これは、その人をインポートしたときに指定したexternal_idで、指定していない場合はDiditのアイデンティティIDです。この値はアクセストークン、IDトークン、GET session/に含まれます。 検証セッションの作成時や取引の送信時には、同じ値をvendor_dataとして使用してください。これにより、認証イベントがコンソール上で、その人の検証や取引と同じ人物に紐づきます。詳しくはイベントとWebhookを参照してください。 vendor_dataは、検証済みのトークンからバックエンドで導出してください。未検証のブラウザのフィールドから取得してはいけません。 どの組み合わせでも共通の連携プロンプトを使用してください。サインイン時に適用されるポリシーについてはボット対策を参照してください。