ホスト型サインインを設定する
サンドボックスアプリケーションに、正確なコールバックURLとWebオリジンを登録します。概要で説明しているとおり、コンソールからサインインオリジン(https://<slug>.sandbox.auth.didit.me)をコピーしてください。このサンプルはブラウザの暗号APIを使用するため、HTTPSが必要です(サンドボックスではlocalhostも使用できます)。登録する内容についてはローカル開発を参照してください。
stateとPKCEベリファイアはアプリケーションが管理します。パスワード、メール、パスキー、電話番号、SSO、必須のMFAの各画面はホスト型サインインが管理します。このコードにAPIキーを含めてはいけません。
auth.js
signIn()を呼び出します。登録済みのコールバックページではhandleCallback()を1回だけ呼び出し、読み込み中の状態を表示し、失敗した場合はそのエラーを表示します。現在のユーザーの取得にはgetSession()を、ログアウトにはsignOut()を使用します。コールバックは、リクエストを送信する前にアドレスバーからコードを削除します。
この最小限のサンプルではトークンをメモリに保持するため、ページの再読み込み後やアクセストークンの期限切れ後には再度サインインが必要です。永続的なセッションが必要な場合は、バックエンドとセキュアなCookieを使用するか、直列化したリフレッシュローテーションを実装してください。リフレッシュトークンをURLやログに含めてはいけません。フロントエンドでのセッション確認は表示を制御するだけです。バックエンドは、保護されたすべてのリクエストで呼び出し元を検証する必要があります。
Authentication SDKのリリースプレビュー
予定されている@didit-protocol/authのコアは、createDiditAuth({publishableKey})、signIn()、handleRedirectCallback()、getSession()、getToken()、onAuthStateChange、signOut()を公開し、アイデンティティにはvendorDataが含まれます。また、デバイスシグナルの自動付与と、verifyToken()を備えたサーバー用エントリーポイントの追加を予定しています。
公開可能キーは、pk_live_(本番アプリケーション)またはpk_test_(サンドボックスアプリケーション)の後に、アプリケーションのオリジンをパディングなしでbase64urlエンコードした文字列が続く形式です。
SDKはAPI呼び出しをそのオリジンに送信します。
このキーは公開情報です。アプリケーションを識別するためのものであり、シークレットではありません。
プレビューにおけるステップアップと再認証
stepUp({ action, amount?, currency?, redirectUri? })は、アプリケーションのPOST step-up/を呼び出し、actionに本人確認が必要かどうかを問い合わせます。actionはpayout、bank、contactのいずれかで、payoutにはamountが必要です。 ステップアップルールのいずれかが適用される場合は、Diditが返す検証ページに遷移します。handleStepUpCallback(url?)は、ユーザーが戻ってくるページで実行します。?step_up=<id>を読み取り、アドレスバーから削除したうえで、GET step-up/{id}/で結果を取得します。reauthenticate({ method? })は、同じユーザーを再度サインインさせます。ホスト型ページ(method: "redirect"、デフォルト)またはパスキー(method: "passkey"、アプリケーションのDiditサインインドメイン上でのみ)を使用します。 ホスト型ページの後は、handleRedirectCallback()で完了させます。 別のユーザーが完了した場合はstep_up_user_mismatchで拒否され、元のセッションは維持されます。
{ id, status, approved, rule, method }で解決されます。statusはnot_required、pending、approved、review、declined、expiredのいずれかです。
redirectUriのデフォルトはクライアントのリダイレクト先アドレスで、アプリケーションに登録済みのリダイレクト先アドレスのいずれかと完全に一致する必要があります。確認が必要な場合、Diditはそれ以外のアドレスを拒否します。
ブラウザから報告された結果は改ざんされる可能性があるため、バックエンドはステップアップに基づいて処理を行う前に、ユーザーのアクセストークンを使ってGET step-up/{id}/でステップアップを再度取得します。
ヘッドレスサインインでは、アプリケーションの保護ルールに該当する場合にprotection_requiredが返されることもあります。
その場合、ユーザーはDiditからメールで届いたコード(protection.verify({ code }))またはパスキー(protection.passkey())で完了させます。methodsには、そのどちらを使用できるかが示されます。
推測したバージョンをインストールしたり、推測したコールバックオプションに基づいてコードを書いたりしないでください。ホスト型のサンプルを置き換える前に、公開されたパッケージのエクスポート、issuer、キーの設定を確認してください。パスワード、メールコード、マジックリンク、パスキー、電話番号、MFA、ソーシャルサインイン、ステップアップ、エージェントの各方式は、そのリリースでサポートされるAPIに依存します。
他のプロダクトを追加する
バックエンドはアクセストークンを検証し(トークンとJWKSを参照)、そのvendor_dataを読み取ります。検証セッションの作成や取引トークンの発行の際に、その値をvendor_dataとして使用してください。サインインに成功しても、いずれかのプロダクトがユーザーを承認したことにはなりません。
リリース前に、有効化済みのサンドボックスアプリケーションで、サインアップ、再度のサインイン、キャンセル、stateの不一致、コードの再利用、パスワードを忘れた場合、MFA、期限切れ、ログアウトを試してください。