メインコンテンツまでスキップ

認可許諾管理

前提知識​

このドキュメントを理解するには、以下の基礎知識が役立ちます：

概要​

idp-serverは、OAuth 2.0/OpenID Connectにおける認可許諾（Authorization Grant） と同意（Consent） を管理します。

認可許諾とは、ユーザーがクライアント（アプリケーション）に対して与えた権限の記録です。

idp-serverでは以下のような用途に対応できます：

  • ユーザーの同意を記録し、次回以降の同意画面をスキップ
  • ユーザーによる同意の取り消し
  • 同意履歴の監査証跡としての保持

idp-serverにおける認可許諾管理の設計思想​

1. スコープ単位の同意記録​

idp-serverは、スコープ単位で同意を記録します。

同意内容:

  • 誰が（ユーザーID）
  • どのクライアントに（クライアントID）
  • どのスコープを（スコープ一覧）
  • いつ許可したか（付与日時）

メリット:

  • 次回以降、同じスコープであれば同意画面をスキップ
  • 新しいスコープが追加された場合のみ同意画面を表示
  • ユーザー体験の向上

2. 同意の取り消し​

ユーザーは、過去に与えた同意を取り消すことができます。

取り消しの効果:

  • 論理削除（revoked_at設定）で履歴保持
  • 関連するアクセストークン・リフレッシュトークンの失効
  • 次回アクセス時に再度同意画面を表示

履歴保持の理由:

  • 監査証跡として保持
  • 統計・分析用途
  • 法的証拠

3. 規約・ポリシーの同意追跡（ConsentClaims）​

idp-serverは、スコープだけでなくクライアントの利用規約（tos_uri）とプライバシーポリシー（policy_uri）への同意も追跡します。

同意比較の仕組み:

  1. 認可リクエスト時に、クライアントの現在の tos_uri / policy_uri から ConsentClaims を生成
  2. 保存済みの AuthorizationGranted 内の consent_claims と比較
  3. 値が一致しなければ interaction_required エラーを返し、再同意を要求

ConsentClaims のデータ構造:

{
  "terms": [
    {"name": "tos_uri", "value": "https://example.com/terms/v1", "consented_at": "2026-01-01T10:00:00"},
    {"name": "tos_uri", "value": "https://example.com/terms/v2", "consented_at": "2026-03-01T14:00:00"}
  ],
  "privacy": [
    {"name": "policy_uri", "value": "https://example.com/privacy/v1", "consented_at": "2026-01-01T10:00:00"}
  ]
}
  • カテゴリ: terms（利用規約）と privacy（プライバシーポリシー）
  • 履歴保持: 規約が更新されるたびに新しいエントリが追加される（上書きではない）
  • 比較ロジック: name + value の一致で判定（consentedAt は比較に使わない）

再同意が必要になるケース:

変更内容結果理由
tos_uri を変更interaction_required新しい利用規約への同意が必要
policy_uri を変更interaction_required新しいプライバシーポリシーへの同意が必要
スコープを追加interaction_required未同意のスコープが含まれる
変更なし同意画面スキップ全ての同意が有効

prompt=none を使用した認可リクエストでは、再同意が必要な場合にユーザー操作なしでは処理できないため interaction_required エラーが返されます。サードパーティアプリはこのエラーを受け取った場合、通常の認可フロー（同意画面付き）にフォールバックする必要があります。

4. 同意履歴の永続化​

同意の記録は、論理削除で履歴を保持します。

3つの状態（スコープ・規約ともに同じライフサイクル）:

状態revoked_at意味動作
有効NULL同意が有効同意画面スキップ
取り消し済み設定済み同意が取り消された再度同意画面を表示
ユーザー削除後設定済みユーザーは削除されたが履歴は保持監査証跡として保持

詳細は concept-13: 監査ログ を参照。

4. ユーザー削除時の扱い​

ユーザーが削除された場合、認可許諾は論理削除されます。

なぜ物理削除しないのか:

  • 監査証跡として保持が必要
  • 「誰が、いつ、どのクライアントに、何のスコープを許可したか」の記録
  • コンプライアンス要件

ユーザー削除フロー:

1. DELETE /users/{userId}
2. UserLifecycleEvent(DELETE)発行
3. idp_user を物理削除
4. authorization_granted は論理削除（revoked_at設定）
5. 関連トークンを失効

ユースケース​

1. 同意のスキップ: 2回目以降のログイン​

初回ログイン時に同意を記録し、次回以降はスキップ。

  • 初回: 同意画面を表示 → ユーザーが承認 → AuthorizationGranted記録
  • 2回目以降: 同じスコープなら同意画面をスキップ
  • 効果: ユーザー体験の向上、スムーズなログイン

2. 同意の取り消し: ユーザーによるアクセス権限の撤回​

ユーザーがクライアントへのアクセス権限を取り消し。

  • 操作: ユーザーが同意を取り消し
  • 処理: revoked_at設定、関連トークン失効
  • 効果: 次回アクセス時に再度同意画面を表示

3. スコープ追加時の再同意​

クライアントが新しいスコープを要求した場合、追加スコープのみ同意。

  • 既存同意: openid, profile（スキップ）
  • 新規スコープ: email（同意画面を表示）
  • 効果: 必要最小限の同意プロセス

4. 規約変更時の再同意​

クライアントが利用規約やプライバシーポリシーを更新した場合、再同意を要求。

  • 変更前: tos_uri = https://example.com/terms/v1 で同意済み
  • 変更後: tos_uri = https://example.com/terms/v2 に更新
  • 動作: prompt=none で interaction_required、通常フローで同意画面を表示
  • 効果: ユーザーは新しい規約に明示的に同意する必要がある

プライバシー規制対応​

GDPR対応​

idp-serverは、GDPR主要条項に対応しています。

Article 7（同意）:

  • 同意取得の証明: AuthorizationGrantedレコード
  • 同意の容易な取り消し: Management API提供
  • 同意履歴の記録: 論理削除（revoked_at）で履歴保持

Article 17（忘れられる権利）:

  • ユーザーデータの物理削除
  • 同意記録の論理削除（履歴保持）
  • 監査ログは保持（法的義務）

Article 20（データポータビリティ）:

  • ユーザーの同意履歴をエクスポート可能
  • JSON形式での提供

その他の規制​

  • 個人情報保護法: 同意取得の記録
  • CCPA: 消費者の削除権（同意記録の論理削除）

セキュリティ考慮事項​

同意の確実な記録​

  • 同意画面の表示: スコープの意味を明確に説明
  • 同意の永続化: データベースに確実に記録
  • 同意のタイムスタンプ: いつ同意したかを記録

同意の取り消しの確実性​

  • 論理削除: revoked_atで取り消し記録
  • トークン失効: 関連するすべてのトークンを失効
  • 再同意の要求: 次回アクセス時に同意画面を表示

同意記録の保護​

  • 改ざん防止: 監査ログと同様のアクセス制御
  • 履歴の保持: 取り消し後も履歴として保持
  • 監査証跡: 同意・取り消し操作をAuditLogに記録

関連ドキュメント​

参考仕様​