はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴セッションをサーバー側で保持する
JavaScriptクイックスタートで説明しているホスト型フローを使用し、サーバーレンダリングのアプリケーション向けに以下の変更を加えてください。ルート名はお客様が実装するアプリケーションのルートであり、DiditのAPIエンドポイントではありません。
Cookieには、ランダムなアプリケーションセッションの参照値のみを、
Secure、HttpOnly、SameSite=Laxを指定し、パスを限定して送信してください。適切な有効期限を設定し、サインイン後に参照値をローテーションしてください。Diditのリフレッシュトークンを、レンダリングされるprops、クライアントコンポーネント、ブラウザのストレージに公開しないでください。トークンとコールバックのレスポンスにはCache-Control: no-storeを使用してください。
レイアウトやmiddlewareでのチェックだけに頼らず、データへのアクセスと変更処理のたびに認可を行ってください。Cookieで認証する変更処理はCSRFから保護してください。ログイン後の遷移先は設定済みのものだけを許可し、クエリ文字列から渡された任意のreturnToのURLは決して許可しないでください。
パッケージのリリースプレビュー
予定しているパッケージでは、サーバーレンダリング向けにmiddleware、サーバー側のauth()、コールバックルート、HttpOnly Cookieのサポートが追加されます。コアの/serverエントリーは、キャッシュされたJWKSを使うverifyToken()を提供する予定です。これらのシンボルは、検証済みのリリースでエクスポートされるまで使用しないでください。それまでは、トークンとJWKSで説明しているとおり、任意のJOSEライブラリを使って自分でトークンを検証してください。
他のプロダクトとの連携
認証セッションの作成と、スコープを限定したモニタリング用トークンの発行は、サーバー側で行ってください。vendor_dataは、検証済みの人物マッピングから導出してください。ブラウザには、認証セッションのURLまたは短期間有効なSDKトークンのみを返してください。DIDIT_API_KEYは公開される環境変数に含めないでください。
認証には既存のWeb認証SDKを、モニタリングには取引送信ガイドを使用してください。どちらもAuthenticationのセッション管理機能ではありません。
リリース前に、コールバックのリプレイ、誤ったstate、期限切れのstate、リフレッシュの競合、失効したセッション、CSRFの拒否、ログアウトをテストしてください。検証の仕様についてはトークンとJWKSを参照してください。