Auth0で実現する動的な同意管理・規約再同意フローの設計と実装

企業のDX推進に伴い、顧客ID統合基盤（CIAM：Customer Identity and Access Management）としてAuth0が採用されるケースが増加しています。CIAMにおいて、利用規約やプライバシーポリシーの適切な同意管理は、コンプライアンス上の必須要件です。また、法的要件の変更に伴う規約改定時には、既存ユーザから遅滞なく「再同意」を取得する仕組みが求められます。
本記事では、Auth0の機能を活用し、ログインフローへ動的に規約同意ステップを介在させるアーキテクチャの設計と、具体的な実装手法について解説します。

概要

本機能は、Auth0 Actionsの「Post-Login」トリガーを起点とするアーキテクチャです。特定の条件（未同意や規約のバージョン更新など）を満たす場合にのみ、ユーザを「Forms」で作成した画面へ誘導し、取得した同意データを「Action（Library※）」経由でユーザプロファイル（app_metadata）に格納します。これにより、アプリケーション側に複雑な同意管理のロジックを実装することなく、一元的なガバナンスを実現します。
※Auth0の「Library」は、ログイン処理などで実行させたい複数のAction（カスタムロジック）を定義・保存しておくためのリポジトリです。

使用するコンポーネントの役割

本フローでは、以下の3つのAuth0コンポーネントを連携させます。

• Trigger (Post-Login)

  Auth0の認証パイプラインにおいて、カスタムロジック（Action）を実行させるタイミング（例: 会員登録時、ログイン時、パスワードリセット時など）を定義するフックポイントです。 今回の場合はユーザがログインした直後やリフレッシュトークンが要求された時に発火し、フロー内に設定されているActionを呼び出します。

• Action

  要件に応じたカスタムロジックを定義可能です。
  今回の場合、ユーザのメタデータ（現在の同意バージョン）と、システムが要求する最新バージョンを比較評価します。最新の規約に同意していない場合にのみ、一時的にログインプロセスを中断してFormsを表示させます。また、フォームで入力された内容を受け取り、Auth0のユーザデータベース（app_metadata）へ書き込むための仲介役を担います。

• Forms

  ノーコード・ローコードで構築可能なホストされたUIエディタです。
  チェックボックスやボタンを配置し、視覚的な同意画面を提供します。Actionとの間でシームレスにパラメータを授受します。

実装例

データ構造例

「利用規約」および「プライバシーポリシー」の同意情報を管理します。 同意状況は、ユーザプロファイルの app_metadata 内に以下のスキーマで保存します。規約ごとのタイムスタンプ、バージョン、同意状態をJSON構造で明示的に管理する設計とします。

{
  "app_metadata": {
    "consents": {
      "terms": {
        "consent_timestamp": "2024-12-12T08:40:21.626Z",
        "consent_version": "1.0",
        "consent_granted": true
      },
      "privacy": {
        "consent_timestamp": "2024-12-12T08:40:21.626Z",
        "consent_version": "1.0",
        "consent_granted": true
      }
    }
  }
}

Action の実装

Actions > Library にて、Post-Loginトリガーに組み込むカスタムアクションを作成します。

1. Secrets変数の定義

規約のバージョンやドキュメントURLはハードコードせず、下記のようにSecrets変数として定義します。

• LATEST_TERMS_VERSION (例: 1.0)
• LATEST_PRIVACY_VERSION (例: 2.0)
• TERMS_URL
• PRIVACY_URL

2. onExecutePostLogin (状態評価とFormsの呼び出し)

ログイン時に現在の同意状況を評価します。
ユーザプロファイルの「app_metadata」に格納されている現在の同意バージョンと、ActionのSecrets変数として定義された「要求される最新バージョン」を比較します。
ここで未同意、または規約のバージョン不一致（改定）を検知した場合、「api.prompt.render」 メソッドを用いてホストされたUI（Forms）へユーザをリダイレクトさせ、ログインフローを一時的に中断します。

3. onContinuePostLogin (同意データの永続化)

ユーザがFormsでの操作を完了し、認証フローに復帰したタイミングで発火し、「app_metadata」を更新します。
ユーザが入力したデータを受信し、新しい同意証跡（日時、バージョン、フラグ）をピンポイントでJSON構造へマージし、「api.user.setAppMetadata」 で永続化させます。

Formsの実装

Auth0がホストするプレゼンテーション層（UI層）として機能します。
Action（onExecutePostLogin）から渡された「最新バージョンのURL」や「現在の同意ステータスの初期値」をパラメータとして受け取り、チェックボックスやリンクを配置したUIを描画します。
ここでは、クライアントサイドでの必須チェックを行い、ユーザが同意した情報をペイロードとしてAction（onContinuePostLogin）へ返却する役割を担います。

本アーキテクチャでは、利用規約およびプライバシーポリシーの同意を取得するため、標準のUIパーツではなく「Customコンポーネント※」を配置して独自の同意チェックボックスを構成します。
具体的なコンポーネントのソースコード実装（DOM操作やバリデーションのJSロジック）は割愛しますが、Formsエディタ上で設定する主要なプロパティと、それぞれのアーキテクチャ上の役割は下表の通りです。
※Customコンポーネントは、Auth0のカスタムドメイン環境でのみ利用可能。

フロー図

運用オペレーション

規約の改定時は、アプリケーションのソースコードを修正・再デプロイする必要はありません。規約同意用ActionのSecrets変数（LATEST_TERMS_VERSION 等）を新しいバージョン番号に更新して「デプロイ」するだけで、即座に全ユーザへの再同意フローがアクティブになります。

おわりに

Auth0 ActionsとFormsを組み合わせた本アーキテクチャは、IDaaSの責務として「認証・認可」と「同意管理」を結合させる非常に強力かつ拡張性の高いアプローチです。
本記事ではご紹介していませんが、ユーザがログイン中の規約更新検知やサービス数や規約数が多い場合の文言の出し分け、アプリケーションメタデータを活用したデプロイ管理など多様なソリューションをご提供可能です。
本記事の実装をベースに、セキュアかつ運用コストの低い同意管理基盤の構築に興味がある方は弊社までお問い合わせください。