中間活動報告会 人材育成WG・技術サブWG / 20250808-oidfj-eduWG-techSWG

Transcript

1. Copyright OpenID Foundation Japan - All Rights Reserved. デジタルアイデンティティ⼈材育成推進ワーキンググループ 中間活動報告会 2025年8⽉8⽇ OpenIDファウンデーション‧ジャパン
2. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬次 1. デジタルアイデンティティのライフサイクル 2. OAuth/OpenID Connectにおけるセッション管理 3. ユーザーアカウント削除時の処理 4. OpenID Connectを活⽤した⾝元確認 5. OAuth/OpenID Connect セキュリティベストプラクティス 本⽇はID管理に必要なライフサイクル、OAuth‧OpenID Connectにまつわるセッション管理、ア カウント削除時の処理、加えて⾝元確認の連携⽅法やセキュリティのベストプラクティスを ご紹介します。 2
3. Copyright OpenID Foundation Japan - All Rights Reserved. 1. デジタルアイデンティティのライフサイクル 3
4. Copyright OpenID Foundation Japan - All Rights Reserved. 本資料はISO/IEC 24760-1:2019で定義されているデジタルアイデンティティのライフサイクルを深 堀りし、デジタルアイデンティティの状態‧遷移ごとのユースケースや、実装時の特徴などを 整理したものです デジタルアイデンティティのサービス関係者が、⾃⾝のサービスに最適なライフサイクルを検討 する際などに、活⽤できる資料をイメージしています 本資料について ISO/IEC 24760-1:2019 本資料 定義した状態・遷移をどのような場合に 適用するか ライフサイクルの状態・遷移の定義 実装するための技術要件 ・・
 ライフサイクルに関する検討事項の例 ライフサイクルをはじめ、アイデンティティ 管理に関する用語を定義 上記ISO/IEC文書で定義されている ライフサイクルの状態・遷移ごとに 特徴を整理 インプット として活用 最適な姿の 検討 デジタルアイデンティティの サービス関係者 4
5. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティ管理に関する⽤語を定義し、アイデンティティとアイデンティティ管理の 中核概念、そしてそれらの関係が規定された⽂書 This document defines terms for identity management, and specifies core concepts of identity and identity management and their relationships. ISO/IEC 24760-1:2019 について 引用: ISO/IEC 24760-1:2019 - 1 Scope 本資料では ISO/IEC 24760-1:2019 で定義されている用語のうち、ライフサイクルに関連する 状態 (stages) と、状態を変更するための 推移 (transitions) を引用し、特徴を整理します 5
6. Copyright OpenID Foundation Japan - All Rights Reserved. 状態 (stages) Unknown Established Active Suspended Archived アイデンティティ管理システム上に存在していない状態 アイデンティティの管理システム上に、アイデンティティを識別するための情報が登録されていない状態 アイデンティティ管理システム上には存在しているが何も権限がない状態 アイデンティティ管理システムに、enrolmentプロセス(後述)で必要な検証されたアイデンティティの情報、提供された アイデンティティの情報を識別するための生成された識別子がアイデンティティとして登録されている状態 アイデンティティ管理システム上に存在していて機能を利用するための権限が付与された状態 アイデンティティ管理システム上に、機能を利用するための権限が付与された状態で、アイデンティティが登録されて いる状態 一時的な機能の利用停止状態 アイデンティティ管理システム上に、機能を利用できない状態で、アイデンティティが登録されている状態 ドメインにエンティティは存在しないが、アイデンティティ管理システム上に情報は残っている状態 アイデンティティ管理システム上に、利用不可の状態で、アイデンティティが登録されている状態。当該アイデンティ ティを登録したユーザーは再度 enrolmentプロセス(後述)により Archived 状態のアイデンティティを使用して別のアイ デンティティを登録できる。この場合作成される別のアイデンティティには Archived 状態のアイデンティティの一部が 複製される場合もある 引用: ISO/IEC 24760-1:2019 - 7.2 Identity lifecycle (日本語訳は本資料の担当メンバー ) Unknown Established 6
7. Copyright OpenID Foundation Japan - All Rights Reserved. 遷移 (transitions) 引用: ISO/IEC 24760-1:2019 - 7.2 Identity lifecycle (日本語訳は本資料の担当メンバー ) [1]Enrolment [2]Activation [4]Identity adjustment [5]Suspension [8]Archive [7]Delete [3]Maintenance [6]Reactivation [9]Enrolment/ restore [7]Delete Unknown Established Active Suspended Archived Established Active Established Suspended Archived Unknown Active Established Unknown アイデンティティ管理システム上に登録されたアイデンティティに機能を利用できるようにする ための情報（権限）の付与 検証、作成されたアイデンティティの情報による、身元確認と登録 アイデンティティ管理システムに登録されたアイデンティティの情報を一部利用不可に する。アイデンティティに紐づくアクセス権限を削除することで実現する アイデンティティ管理システムに登録されたアイデンティティの Activationに関する情報の更新 アイデンティティ管理システムに登録されたアイデンティティの情報を完全に削除する アイデンティティ管理システムに登録されたアイデンティティ情報の一部削除。統計処理にの み利用可能であり、エンティティ (実ユーザー)からの追加情報と関連した場合のみ利用可能 Suspensionからの復帰 アイデンティティ管理システムに登録されたアイデンティティの情報の更新 アイデンティティ管理システムに登録されたアイデンティティの情報を完全に削除する Enrolmentプロセスであり、身元確認で利用されるアイデンティティの情報の一部は、 アイデンティティ管理システムから取得される 7
8. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティライフサイクル 引用: ISO/IEC 24760-1:2019 - Figure 1 - Identity lifecycle 5種類の状態と、状態を変更するための推移により、ライフサイクルを管理する 8 Active Suspended Archived Unknown Established Enrolment Activation Identity adjustment Suspension Archive Delete Maintenance Reactivation Enrolment/restore Delete
9. Copyright OpenID Foundation Japan - All Rights Reserved. Unknown 実装が もたらす効果 • 管理者のIdentity登録 (本フェーズ) と、当人による有効化 [②Activation] を分けることができる • サービスへの新規登録時に、 Activationと分けることで、ユーザーの負担を分散させる ◦ Activationまで一気通貫で行うと、時間がかかりユーザー離脱の可能性が上がる サービスへの 実装例 • (主にエンタープライズ環境で )着任前に管理者が Identity登録を行い、当人の着任後に有効化する • 登録されたメールアドレス宛に送られたメールより、リンクをクリックしないと機能が使えないサービス • 身元確認 (Identity proofing)を完了しないと、機能を使えないサービス 実装方法／ 技術 • サービスで求められる検証を行った結果、確からしい場合ユニークな識別子を発行する 想定される 脅威／不正例 • 実在性の不確かな Identityの登録 (例: 偽名, 住所に空き家を指定 ) ◦ スクリプト等でEnrolmentを自動化し、Identityを大量発行 (例: 登録特典の不正入手 , 給付金の不正申請 ) • 当人性の不確かな Identityの登録 (例: 別人のメールアドレスの利用や入力ミス ) 脅威／不正の 対策例 • [実在性]身元確認での検証 , 不審な振る舞いの検知・防御 (例: 同一端末からのアカウント作成制限 ) • [当人性]サービス単独では困難。公的個人認証 (JPKI)等の信頼される外部アイデンティティが必要となる ◦ JPKIは利用時にマイナンバーカードを用いた当人認証 (Authentication)により当人性を確認できる Enrolment Established 登録された識別⼦を⽤いたIdentityが⽣成され、アイデンティティ固有の値が割り振られ、 ドメインに登録される。リソースはまだ利⽤できない ①UnknownからEstablished 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます 9
10. Copyright OpenID Foundation Japan - All Rights Reserved. Established 実装が もたらす効果 • メールアドレス／電話番号等の実在性を検証することで、なりすましの抑止や登録時の入力ミスを登録者に気づかせる ことができる • 身元確認 (Identity Proofing) を、有効化する機能に応じたレベルで実装できる サービスへの 実装例 • 身元確認の完了後に、全機能が利用可能となるサービス ◦ 法令等で本人確認が義務付けられている機能が対象になることが多い ) 実装方法／ 技術 • メールアドレスの検証が必要な場合、 ID Token の email_verified を利用し、Enrolment と Activation を同時に実施すること も考えられる 想定される 脅威／不正例 • エビデンスの改ざん (例: 偽造免許証を使った撮影による身元確認の突破 ) • 合成アイデンティティ詐称 (Synthetic Identity Fraud) ◦ 窃取した実在の属性情報と、実在しない不正な属性情報を組み合わせアイデンティティを作成 脅威／不正の 対策例 • 改ざんの難しい身元確認方式の採用 (例: ICチップの読み取り ) • 複数の属性情報を用いた検証 Activation Active 登録されたアイデンティティに情報を追加し、利⽤可能なリソースを使うことができる ②EstablishedからActive 10 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます
11. Copyright OpenID Foundation Japan - All Rights Reserved. Active 実装が もたらす効果 • アカウント作成時に検証した情報との差異が生じた場合に、再検証を求めることができる • (デメリット)ユーザーはリソースが使用不可となるため、理由が不明瞭だと体験が低下する サービスへの 実装例 • 重要な属性情報 (例: メールアドレス、生年月日 ) の変更時にその確実性を検証させる • 前回の身元確認時に利用した属性情報が更新された後に、身元確認が必要な機能を利用する場合 実装方法／ 技術 • Established に戻るため、必要に応じてサービス利用に制限をかける（機能へのアクセスを制限する） • Suspension との違いは再度の Activation の要否（メールアドレス変更後の再確認などが該当） 想定される 脅威／不正例 • 当人認証を不正に突破した攻撃者 (なりすましサインインに成功 )が、攻撃者自身の属性情報に変更する 脅威／不正の 対策例 • 属性情報の更新時に通知し、正当な利用者が不正を検知可能とする ◦ メールアドレスの変更時は、変更前のメールアドレスにも通知する Identity adjustment Established アイデンティティの情報が更新され、アクティベーション状況が修正された状態 (再度アクティベーションが必要) ③ActiveからEstablished 11 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます
12. Copyright OpenID Foundation Japan - All Rights Reserved. Active 実装が もたらす効果 • 不正な振る舞いを検知した際に、誤検知時の速やかな復旧と被害の拡大抑止を両立できる • 利用規約の違反が疑われた際に、管理者側で調査のための無効化が行える サービスへの 実装例 • リスクベース認証製品を活用し、高リスクな振る舞いを検知した際のアイデンティティ一時停止 • 利用規約の違反が疑われるアカウントに対する、サービス側でのアイデンティティ一時停止 (いわゆるBAN) 実装方法／ 技術 • Suspendedの場合はログイン不可となるようアクセスをコントロールする • DBでステータス管理している場合は Active へ復帰可能なように レコードは削除しない 想定される 脅威／不正例 *1 • 本状態に遷移した旨を虚偽で伝え、フィッシングサイトに誘導する ◦ 例: 「アカウントを無効にしました。解除するには手続きを行ってください 」といったフィッシング 脅威／不正の 対策例 *1 • Suspended状態になった旨をメール等で通知するが、手続きリンクは 記載しない ◦ ブックマークやネイティブアプリからの手続きを正当なユーザーフローとし、左記フローを周知する ▪ どうしてもメールに記載する場合、 BIMI等のメールなりすまし対策で公式アイコンを表示する方法や、正当 なメールアドレスの周知も考えられる。しかし上記対策よりは効果が低いと想像される • サインインや重要な操作は、アクティビティログとしてユーザーが確認できるようにする Suspension Suspended アイデンティティ管理システムに存在するが、リソースにアクセスできない状態 (⼀時的にアクセス権を無効にする) ④ActiveからSuspended *1: 実際には [Suspended]→[Active]を行うReactivationの遷移が該当する。実用性を優先し、セットで考えることが多いSuspensionの遷移にも記載する 12 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます
13. Copyright OpenID Foundation Japan - All Rights Reserved. Active 実装が もたらす効果 • 法令等で長期保存が必要なアイデンティティ情報を、性能・セキュリティの品質を保ちつつ保管できる ◦ 別のデータベースにデータを移動するのであれば検索性能 UX向上・改善 ◦ マスキングした状態でアーカイブ化されるならば、セキュリティ向上 (漏えいリスクの低減 ) サービスへの 実装例 • ユーザーが自身のアイデンティティを削除した後、復元可能な一定期間を設ける • 削除したアイデンティティを定められた期間保管する 実装方法／ 技術 • DBでステータスを管理する場合、ステータスを Archivedに変更するか、異なるテーブルへ退避する • 異なるテーブルへ退避する場合は、既存レコードを物理削除、論理削除、ステータス更新の 3つの手段が 考えうる 想定される 脅威／不正 • データベース情報の漏えい件数が、アクティブユーザー数を大きく超える可能性がある ◦ 復元可能な状況を維持し続けると、必要以上に個人データを保有し続けることになる 脅威／不正の 対策 • Archivedを維持し続ける条件、 Unknownへの遷移 (Delete) 条件を明確に定め、必要な場合のみ Archiveする Archive Archived アイデンティティ管理システムに登録されたアイデンティティ情報の⼀部削除。統計処理にのみ利⽤ 可能であり、エンティティ(実ユーザー)からの追加情報と関連した場合のみ利⽤可能 ⑤ActiveからArchived 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます 13
14. Copyright OpenID Foundation Japan - All Rights Reserved. (中間報告時点)学びの⼤きかった点 最適なライフサイクルはサービスにより異なるため、ISO/IEC 24760-1:2019 の定義は標準的な概念 として認識し、サービスの特性を考慮し具体的なライフサイクルを決定するのが好ましいと考えた • Unknown → Active となるアカウント作成 ◦ 身元確認を求めないサービスなど、 Activationのユーザー負担が小さいユースケースでは、 アカウント作成プロセスの中に Activationが含まれるケースがある ◦ しかしIdentity Lifecycleは、Enrolment, Activationが分離しており、[Unknown] (activation)=> [Active] の遷移 は定義されていない ▪ EnrolmentとActivationを同時に行っているサービスも実在すると想定される • 利用規約違反等でアカウントを一時停止し、その後削除する (アカウント停止 ) ◦ 管理者側でいったん Suspended状態にし、違反の詳細を確認するユースケース ◦ 重大な違反の際には削除も考えられるが、 [Suspended]からの遷移は、[Active] のみ定義されている ▪ [Suspended]からの[Archived] or [Unknown] を実装しているサービスも実在すると想定される 脚注: 本資料はサブWG内で作成・レビュー中であり、参加メンバーの推測や印象・感想等を含みます 14
15. Copyright OpenID Foundation Japan - All Rights Reserved. Appendix: 引⽤元の資料 • ISO/IEC 24760-1:2019 ◦ アイデンティティ管理に関する用語を定義し、アイデンティティとアイデンティティ管理の 中核概念、そしてそれらの関係が規定された国際規格 ◦ 改訂版として、ISO/IEC 24760-1:2019/Amd 1:2023 も存在する。本資料は無料で入手可能な ISO/IEC 24760-1:2019を引用元としている ◦ https://www.iso.org/standard/87485.html • NIST SP 800-63-4, Digital Identity Guidelines ◦ 米国国立標準技術研究所 (NIST) が発行する、デジタルアイデンティティに関する特別刊行物 (Special Publications) ◦ 2025年7月31日にRevision 4のFinalバージョンが公開された ▪ https://csrc.nist.gov/pubs/sp/800/63/4/final 15
16. Copyright OpenID Foundation Japan - All Rights Reserved. Appendix: 関連⽤語集 • ISO (国際標準化機構 : International Organization for Standardization) 各国の代表的標準化機関から成る国際標準化機関で、電気・通信及び電子技術分野を除く全産業分野 （鉱工業、農業、医薬品等）に関する国際規格の作成を行う • IEC (国際電気標準会議 : International Electrotechnical Commission) 各国の代表的標準化機関から成る国際標準化機関であり、電気及び電子技術分野の国際規格の 作成を行う 16
17. Copyright OpenID Foundation Japan - All Rights Reserved. 登壇者紹介 私自身が ID 初学者ですので、初学者なりの視点で、 初学者の方に伝わるよう説明を考えました。 同じくこれから ID を学ぶみなさま、一緒に頑張って いきましょう！ 吉村 株式会社オプティム
18. Copyright OpenID Foundation Japan - All Rights Reserved. 注意事項 18 わかりやすく説明をするために詳細をお伝えしきれていません。 参考⽂献で⽤いられている⽤語は置き換えている部分があります。 詳細を確認する際は⼀次情報をご参照ください。
19. Copyright OpenID Foundation Japan - All Rights Reserved. 技術的なポイント（Enrolment） 19 1. デジタルアイデンティティのライフサイクル
20. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録（= アカウント登録） 登録に関する状態と遷移 • Unknown • アイデンティティが存在しない状態 • Established • 必要なアイデンティティ情報の検証が完了 • Identity Register に情報が登録された状態 • Active • サービスを利⽤できる状態 • Enrolment • 本⼈確認と本⼈情報を含む ID の登録 • Activation • サービスにアクセスできるよう本⼈情報に追加情報を加える 20 Unknown ISO/IEC 24760-1:2019 での Identity lifecycle Established Enrolment Active Activation ※ ここでの「登録」はサービスへのアカウント登録プロセス全体を指す
21. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する状態と遷移 21 Unknown ISO/IEC 24760-1:2019 での Identity lifecycle Established Enrolment Active Activation Enrolment Activation Activation ※ メールアドレスの確認が終わるまでデータを作らない（ = ② の時点で Establised になる）など、複数のケースが考えられる
22. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 「登録」という⽂脈で考えるべきこと • ユーザーの識別⼦ • 例：ランダムなユーザー ID を割り当てる • Enrolment で作成 • ⾝元確認 • 例：マイナンバーカードに含まれた情報の利⽤ • （必要な場合）Enrolment または Activation で登録 • 当⼈認証 • 例：パスワードの登録 • （必要な場合）Enrolment または Activation で登録 • その他、サービス利⽤にあたって必要な情報 • 例：EC サイトに設定する配送先住所 • （必要な場合）Enrolment または Activation で登録 22 Unknown ISO/IEC 24760-1:2019 での Identity lifecycle Established Enrolment Active Activation ※ 各プロセスの実施タイミングや要否は、サービスの性質や実装によって異なる ※ 例えばサービスの一部機能を利用する場合にのみ身元確認が必要、といったケースでは、アイデンティティの登録とは別の任意のタイミングで実施することも 考えられる
23. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ユーザーの識別⼦ • 「ユーザーの識別⼦」には 2 つの⽂脈がある • システム上で利⽤される識別⼦ (ID Token の sub 相当) • 正確には、登録 (Enrolment) される Entity を参照するための Identifier • Enrolment の過程で作成される • ログイン時に⼊⼒する ID • ⼀意な属性情報 23
24. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ユーザーの識別⼦（システム上で利⽤される識別⼦） • 識別⼦は⼀意でなければならない • 識別⼦は変更されてはならない • 識別⼦が再利⽤されることは防ぐべき • 過去にサービスを利⽤していた他⼈の情報が紐づく可能性がある • ユーザーの削除時に、識別⼦だけは残しておくなど考慮が必要 24
25. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ユーザーの識別⼦（ログイン時に⼊⼒する ID） • システムが決定することも、ユーザー⾃⾝が決定することも考えらえる • 例：ランダムな識別⼦をシステムが⽣成し、割り当てる • ※ システム上で利⽤される識別⼦をそのまま使⽤するなど • 例：好みのユーザー ID をユーザー⾃⾝が決定する • 例：メールアドレスなどの属性情報を使⽤する • ※ 使⽤する属性情報がユニークであることが前提 25
26. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ⾝元確認に必要な情報 • （必要な場合）Enrolment または Activation で登録 • 例：⾝分証を提⽰できない場合にユーザー登録を⾏わせない • このケースでは Enrolment で登録させている • 例：サービスへの初期登録後に本⼈確認プロセスを開始できる • このケースでは Activation で登録させている • サービス利⽤に必須でない場合には Active になった後に追加させるのも OK 26
27. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ⾝元確認に必要な情報 • サービスで必要な保証レベル (IAL) に沿ったものが必要 • IAL: Identity Assurance Level • ⾝元確認の保証レベルをレベル 1 から 3 で表す • NIST SP 800-63A に規定されている • ⾝元確認は以下のステップにより構成される • Resolution: 中核となる属性情報 (Core Attributes) とその証拠 (Evidence) を収集する • Validation: 属性情報と証拠が本物か、有効かなどを確認する • Verification: 申請者が提⽰された証拠の正当な所有者か確認する 27
28. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 当⼈認証に必要な情報 • （必要な場合）Enrolment または Activation で登録 • 例：サービスへの初期登録時 (Enrolment) に、設定したいパスワードを⼊⼒させる • 例：サービスへの初期登録でメールアドレスを⼊⼒し、そこに初期設定メールを送る • メールアドレスの⼊⼒は Enrolment で、パスワード設定は Activation • ⼀時的なゲストユーザーとして利⽤する場合など、当⼈認証が不要なケースもある • サービスで必要な保証レベル (AAL) に沿ったものが必要 • AAL: Authentication Assurance Level • 当⼈認証の保証レベルをレベル 1 から 3 で表す • NIST SP 800-63B に規定されている • 詳細は 2024 年度活動報告会での内容に記載 • デジタルアイデンティティ技術 認可‧ID連携‧認証 応⽤ / 20250114-OIDF-J-EduWG-TechSWG - Speaker Deck • アカウントの復旧（リカバリ）を踏まえると、⾝元確認の考慮も必要 • 必要に応じて IAL（⾝元確認の保証レベル）を参照する 28
29. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 その他、サービス利⽤にあたって必要な情報 • （必要な場合）Enrolment または Activation で登録 • 例：EC サイトにて、配送先住所が設定されていない場合にサービスを利⽤できない • Enrolment で登録させることも Activation で登録させることも考えられる • サービス利⽤に必須でない場合には Active になった後に追加させるのも OK 29
30. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 ⾝元確認プロセスに対する脅威 4 つの⼀般的なカテゴリがある • なりすまし • Attacker が他の正当な個⼈を騙る試み • 虚偽‧詐称表現 • Attacker が虚偽の Identity を作り出す、あるいは Identity についての虚偽の Claim を⾏う • ソーシャルエンジニアリング • Attacker が欺瞞や強制により被害者に対して⾝元確認プロセス中に何らかの⾏動を取らせる • インフラストラクチャ • Attacker がインフラストラクチャ、データ、ソフトウェア、あるいは CSP による Identity Proofing プロセスを⽀える⼈たちを危殆化させる可能性 インフラストラクチャの脅威は、従来のコンピュータセキュリティコントロール（例：侵⼊防御、記録 保持、独⽴監査）によって考慮されており、このドキュメントの範囲外であるため、NIST SP 800-63-4 では、なりすましと虚偽‧詐称表現の脅威を中⼼に説明している 30
31. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • ⾃動化された Enrollment 試⾏ (Automated Enrollment Attempts) • 攻撃者はスクリプトと⾃動化されたプロセスを活⽤して、⼤量の Enrollment を迅速にする • 例: ボットが盗まれたデータを利⽤して給付⾦の申請を⾏う • 対策: • Web Application Firewall (WAF) 制御やボット検出技術 • Out-of-band でのエンゲージメント（確認コードなど） • ⽣体認証と⽣体検知メカニズム • 不正なトラフィックの兆候を特定するためのトラフィックおよびネットワークの分析 31
32. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • Evidence 改ざん (Evidence Falsification) • 攻撃者がアイデンティティを主張 (Claim) するために Evidence を作成または改ざんする • 例: 偽造された運転免許証が Evidence として使⽤される • 対策: • 権威のある、または信頼できる情報源による Core Attributes の検証 • 提⽰された Evidence の物理的またはデジタルなセキュリティ機能の検証 32
33. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • 合成 Identity 詐称 (Synthetic Identity Fraud) • 攻撃者が、実在しない⼈物に関連付けられた Identity の Evidence を偽造する • 例: クレジットファイルを作成するために偽名でクレジットカードを開設する • 対策: • Identity Evidence の収集 • 公的または信頼できる情報源による Core Attributes の検証 • 検証済みの Identity Evidence または⽣体認証データと Applicant の⽣体情報⽐較 • 重要な (vital) 統計リポジトリ（例：死亡者マスターファイル）との照合 33
34. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • Identity 不正利⽤ (Fraudulent Use of Identity (Identity Theft)) • 攻撃者が他⼈の Identity または Identity Evidence を不正に使⽤する • 例: ある⼈が盗まれたパスポートを使⽤する • 対策: • 検証済みの Identity Evidence または⽣体認証データと Applicant の⽣体情報⽐較 • Applicant の実在を確認するためのなりすまし攻撃検出対策 • Out-of-band でのエンゲージメント（確認コードなど） • 重要な (vital) 統計リポジトリ（例：死亡者マスターファイル）との照合 • 潜在的な悪意あるアカウント開設の兆候を特定するための、詐欺、取引、および⾏動 分析機能 34
35. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • ソーシャルエンジニアリング (Social Engineering) • 攻撃者が正当な Applicant に対して、虚偽の⼝実のもとで Identity Evidence を提供したり、 本⼈確認プロセスを完了するよう促す • 例: 攻撃者が将来の雇⽤主を装って、個⼈の Identity Evidence を提出させる • 対策: • 強制や苦痛の兆候を特定するための Trusted Referee のトレーニング • 検証済みアドレスへの Out-of-band でのエンゲージメントと Proofing の通知 • ⼀般的な脅威や⼿法に関するエンドユーザーへの情報提供とコミュニケーション • 対⾯での⾝元確認オプションの提供 35
36. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • 虚偽の Claim (False Claims) • 攻撃者が正当な Identity に虚偽の属性や情報を関連付ける • 例: ある州の住⺠のみが利⽤可能な給付⾦を取得するために、州に居住していると虚偽の申告 をする • 対策: • トラフィックに対する地理的制限 • 公的または信頼できる情報源による Core Attributes の検証 36
37. Copyright OpenID Foundation Japan - All Rights Reserved. アイデンティティの登録 登録に関する攻撃や脅威とその対策 • 動画または画像インジェクション攻撃 (Video or Image Injection Attack) • 攻撃者が偽の動画フィードを作成し、実在の⼈物になりすます • 例: 盗まれた運転免許証に描かれた個⼈になりすますためにディープフェイク動画を使⽤する • 対策: • アクティブおよびパッシブな PAD (プレゼンテーション攻撃検出) の組み合わせの使⽤ • デバイスとマッチングを実⾏するサーバー間の通信に認証された保護チャネルの使⽤ • ⽣体認証センサーの認証 • 偽造や改竄の兆候を検出するための、受信する動画および画像ファイルの監視と分析 • active countermeasures の使⽤ 37
38. Copyright OpenID Foundation Japan - All Rights Reserved. 登壇者紹介 これからIDを学びたい方でもわかるよう ミスリードがないように資料を作成しました。 IDに興味を持って正しく学ぶきっかけになれば幸いです。 持⽥ 捷宏 LINEヤフー株式会社
39. Copyright OpenID Foundation Japan - All Rights Reserved. 技術的なポイント（Reactivation） 39 1. デジタルアイデンティティのライフサイクル
40. Copyright OpenID Foundation Japan - All Rights Reserved. 参考⽂献：ISO/IEC 24760-1:2019 40 これから補⾜する「Reactivation」について、ISO/IEC 24760-1:2019で定義され ている「Identity lifecycle」におけるその位置付けを振り返ります。 •参考⽂献 ISO/IEC 24760-1:2019, IT Security and Privacy — A framework for identity management — Part 1: Terminology and concepts. https://www.iso.org/standard/77582.html
41. Copyright OpenID Foundation Japan - All Rights Reserved. • Active • サービスを利⽤できる状態 • Suspension • サービス利⽤権限の無効化 • Suspended • ⼀時的なサービス利⽤不可な状態 • Reactivation • アカウントリカバリの実施 Reactivation ー 関連する状態と遷移 41 Reactivationは⼀時的なサービス利⽤不可な状態から サービスを利⽤できる状態復帰する遷移になります。 Active ISO/IEC 24760-1:2019 での Identity lifecycle Suspended Suspension Active Reactivation ISO/IEC 24760-1:2019, IT Security and Privacy — A framework for identity management — Part 1: Terminology and concepts. https://www.iso.org/standard/77582.html
42. Copyright OpenID Foundation Japan - All Rights Reserved. Reactivation ー ユーザー体験イメージ 42 サンプルサービス サインイン ①認証する Active ISO/IEC 24760-1:2019 での Identity lifecycle Suspended Suspension Active Reactivation 現在お客様のサービス利用を 一時的に停止しています 復旧 ②Suspended状態であることを伝える サンプルサービス サンプルサービス ④サービス利用可能 ＊＊＊＊＊＊ ③リカバリコードを入力する サンプルサービス アカウントリカバリ リカバリコード 復旧 サービス利用可能 Reactivationのユーザー体験のイメージは下記の通り になります。 Reactivation Suspended Active
43. Copyright OpenID Foundation Japan - All Rights Reserved. •参考⽂献 NIST Special Publication NIST SP 800-63B-4, Digital Identity Guidelines Authentication and Authenticator Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf 【補⾜】 「Reactivation」において認証⼿段が停⽌される場合（例：乗っ取りによるSuspension）には、「Account Recovery」 の⾝元確認や認証⼿段の再設定が補完的に⽤いられることがあります。ただし、「Reactivation」はサービス側主導の⼀ 時停⽌からの復旧、「Account Recovery」はユーザー側の認証⼿段喪失による復旧という違いがあり、IDの状態 （Suspended / Active）も異なる場合があるため、必ずしも⼀致しません。両者は異なる⽂脈にあるものの、復旧のため の⾝元確認など共通点があるため、そこにフォーカスします。 参考⽂献：NIST SP 800-63B-4 43 以降ISO/IEC 24760-1:2019で定義された「Reactivation」をNIST SP 800-63B-4の 「Account Recovery」を基に技術的なポイントを補⾜します。
44. Copyright OpenID Foundation Japan - All Rights Reserved. NISTで定義されているアカウントリカバリ概要 ユーザーがサービスから要求されるAALでの認証に必要な認証⼿段を失った状態 (*)から回復するプロセス。 1. アカウントリカバリ⼿段の実施（ユーザー通知） 2. 認証⼿段の再設定（ユーザー通知） アカウントリカバリは通常利⽤が想定されないため⼀般的に認証よりも利便性が 低い場合がある。 44 NIST SP 800-63B-4 で定義されているアカウントリカバリの概要を説明します。 【⼀般的に想定される認証器の制御を失うユースケース】(*) • 乗っ取り起因でSuspensionが起きた場合にサービス提供者側で認証⼿段を停⽌する NIST Special Publication NIST SP 800-63B-4, Digital Identity Guidelines Authentication and Authenticator Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
45. Copyright OpenID Foundation Japan - All Rights Reserved. アカウントリカバリ⼿段⼀覧 45 • Saved recovery codes ◦ アカウント作成時にリカバリコードを発⾏/保存しておきアカウントリカバ リ時に確認する⽅法 • Issued recovery codes ◦ アカウントリカバリ時にリカバリ⽤アドレス（メールなど）にリカバリコー ドを送信して確認する⽅法 • Use of recovery contacts ◦ アカウントリカバリ時に信頼できる第三者にリカバリコードを送信して確認 する⽅法 • Repeated identity proofing ◦ アカウントリカバリ時にアカウント作成時に⾏った⾝元確認のプロセスを再 実施する⽅法 NISTで定義されている4種類のアカウントリカバリ⼿段を説明します。 ＊Issued recovery codesとの違い：家族や代理人のサポートが必要なユースケースを考慮 NIST Special Publication NIST SP 800-63B-4, Digital Identity Guidelines Authentication and Authenticator Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf ＊リカバリコード： 少なくとも 64ビットのエントロピーを含む 数値または印刷可能な ASCII文字または 2次元コード ＊リカバリコード： 少なくとも 6桁の10進数（または同等の情報量の数値または印刷可能な ASCII文字または 2次元コード）
46. Copyright OpenID Foundation Japan - All Rights Reserved. アカウントリカバリの通知要件（1/2） • 通知先選定要件（必須） ◦ 郵送先住所を除くすべての通知先に通知しなければならない ◦ ただし下記の場合郵送先住所にも通知しなければならない ▪ 郵送先住所以外の通知先がない ▪ AAL3の認証⼿段を持つアカウントのアカウントリカバリである ▪ リカバリコード送信先しかない（送信先乗っ取られのユースケースを考慮） ◦ 通知先 ▪ 郵送先住所 ▪ Eメールアドレス ▪ テキストメッセージや⾳声メッセージの送信先（例：電話番号） ▪ プッシュ通知 46 アカウントリカバリ⼿段実⾏時に必須化されている通知要件について説明します。 通知は不正⾏為の可能性の気づきに役⽴ちます。 NIST Special Publication NIST SP 800-63B-4, Digital Identity Guidelines Authentication and Authenticator Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
47. Copyright OpenID Foundation Japan - All Rights Reserved. アカウントリカバリの通知要件（2/2） • 通知先登録要件（必須） ◦ サービス提供者は2つ以上の通知先をサポートしなければならない ◦ いずれか1つは⾝元確認のプロセスで検証されなければならない • 通知先変更要件（推奨） ◦ AAL2以上（AAL1が最⼤の場合AAL1）の状態で通知先を変更できるようにす べき • 通知内容要件（必須） ◦ ユーザーが通知を受けとった結果アカウントリカバリ処理を拒否したい場 合に備えて、お問い合わせ先を含む明⽰的な指⽰を記載しなければならない 47 NIST Special Publication NIST SP 800-63B-4, Digital Identity Guidelines Authentication and Authenticator Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf アカウントリカバリ⼿段実⾏時に必須化されている通知要件について説明します。 通知は不正⾏為の可能性の気づきに役⽴ちます。
48. Copyright OpenID Foundation Japan - All Rights Reserved. 2. OAuth/OpenID Connectにおけるセッション管理 48
49. Copyright OpenID Foundation Japan - All Rights Reserved. 登壇者紹介 エンジニア歴＝ID歴 ⾃社IDaaSの開発‧運⽤保守を担当しています 花井 杏夏 伊藤忠テクノソリューションズ デジタルIDは学ぶことが多く⼤変ですが、その分新 しい発⾒も多く、⽇々楽しみながら取り組んでおり ます。普段はハトンと呼んでもらっています。 飯岡 巧⺒ フリー株式会社
50. Copyright OpenID Foundation Japan - All Rights Reserved. セッションとは？ 50 2. OAuth/OpenID Connectにおけるセッション管理
51. Copyright OpenID Foundation Japan - All Rights Reserved. はじめに • 通信の開始から終了までを表す単位 →本章ではウェブサーバーへの通信を⽬的として「セッション」を取り扱う • Webにおけるセッション ◦ ユーザーがWebサイトに訪れてから離脱するまでの⼀連の⾏動の単位や⼀連の⾏ 動を⾏うために情報を⼀時的に保持する仕組み 51 「セッション」とは？ ECサイト セッ ション 認証情報入力 ログイン後画面表示 商品閲覧、カート登録 セッションID、ログイン したユーザー情報、閲 覧履歴、カートの中身 など 購入後画面表示 セッション生成 ログアウト（利用終了） セッション追加 セッション終了
52. Copyright OpenID Foundation Japan - All Rights Reserved. はじめに • なぜセッションの概念が重要なのか？ ◦ Webの世界はステートレス＝通信ごとに状態（セッション）を保持しな い仕組みとなっている ◦ 各リクエストは独⽴して処理され、過去のリクエストをサーバーが記憶 できない →「セッション管理」の仕組みがないと、認証状態などを維持‧管理す ることができない 52 OAuth/OpenID Connectでセッションが果たす役割
53. Copyright OpenID Foundation Japan - All Rights Reserved. はじめに • OAuth/OpenID Connectにおける考慮 ◦ Webサーバーが複数（OP/RP）登場するため、単⼀ではなくそれぞれで セッション管理を考える必要がある ▪ OP、RPそれぞれのセッション保持状況 ▪ セッション間の関連性、連動性、など →シングルサインオンやログアウト時の考慮などに繋がる 53 OAuth/OpenID Connectでセッションが果たす役割
54. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect とセッションの関連 54 2. OAuth/OpenID Connectにおけるセッション管理
55. Copyright OpenID Foundation Japan - All Rights Reserved. ユーザー ⑥ログイン完了 セッション確⽴までのフロー 55 RP、OPが別ドメインであることを前提にした場合、ユーザー/OP間、ユーザ/RP 間で別々に⽣成‧管理される。⼀例としてどちらもセッションがない状態からの フローを次項で説明する。 ①アクセス ③ログイン情報入力依頼 ④ログイン情報入力 RP（Relying Party） XXXでログイン YYYでログイン メールアドレスを入力 次へ OP（OpenID Provider） メールアドレス パスワード ログイン ⑤認証応答 ②認証要求
56. Copyright OpenID Foundation Japan - All Rights Reserved. OPによるユーザー認証とセッション確⽴ 56 OPでは、ユーザーがログイン画⾯でクレデンシャル（例：IDとパスワード）を ⼊⼒し、それが正しいと判断されると、OP内部でユーザーのセッションが開始 される。 💡 参考 ID/PW以外にも様々な認証方式がある。 例：生体認証（指紋認証・顔認証）、 OTP（SMS・メール・TOTP）、パスキー、ソーシャルログイン OP ユーザー OP Cookie １．ログイン情報入力依頼 ２．ログイン情報（ID/PWなど） ４．セッション開始 ３．ログイン情報の検証
57. Copyright OpenID Foundation Japan - All Rights Reserved. RPによるIDトークンの検証とセッション確⽴ 57 OPで認証が完了すると、RPはIDトークンを受け取ることができる。 RPはこのIDトークンを検証し、ユーザーが正しく認証されたことを確認できた場 合、⾃⾝のセッションを新たに確⽴する。 OP ユーザー OP Cookie １．ID連携 ２．IDトークンを検証 　署名/発行者/期限など ３．セッション開始 RP RP Cookie IDToken 💡 参考 IDトークンに含まれる acr クレームで認証強度や認証方式を確認することができる。
58. Copyright OpenID Foundation Japan - All Rights Reserved. ユーザー ユーザとRP‧OPの間はセッションで管理 58 先述した通り、ユーザー/RP間、ユーザー/OP間の２つはブラウザを介したセッ ションで維持‧管理される。 セッション セッション RP（Relying Party） XXXでログイン YYYでログイン メールアドレスを入力 次へ OP（OpenID Provider） メールアドレス パスワード ログイン トークン
59. Copyright OpenID Foundation Japan - All Rights Reserved. ユーザー RP/OP間のトークンとは？ 59 ユーザー/OP間、ユーザ/RP間の説明を本章で取り上げた。 次章は、RP/OP間のトークンについて説明する。 セッション セッション RP（Relying Party） XXXでログイン YYYでログイン メールアドレスを入力 次へ OP（OpenID Provider） メールアドレス パスワード ログイン トークン
60. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持と セッションの関連 60 2. OAuth/OpenID Connectにおけるセッション管理
61. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 OpenID ConnectはOAuth 2.0の上にIdentityレイヤを乗せる形で実現されている。 このためRPは、OPが発⾏したAccess Tokenを利⽤してUserInfo Endpointから継続的に最 新のユーザー情報を取得するなど、OAuth 2.0の仕組みを活⽤するケースが多くある。 本章では、RPのセッションとAccess Tokenをどのように関連付けて安全に管理すべきかに ついて解説する。 61 OpenID ConnectとAccess Tokenの関係性
62. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 Access TokenやRefresh Tokenをどのように保持するかは、サービスのユースケースによっ ていくつかパターンがある。 ユーザーがRPにログインしている間だけ、Tokenをセッションに紐づけて保持する • ユースケース • Webサイトの閲覧中、写真を外部サービスから取得し表⽰する。 ユーザーに最新のToken紐づけ、ユーザー操作とは⾮同期にリソースアクセスする • ユースケース • カレンダー情報を1時間ごとに同期する。 • 連絡先の⼀括インポート処理をバックグラウンドで実⾏する 62 RPにTokenを保持するパターン
63. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 保持しているTokenは、その役割を終えたり無効になったりした際に、速やかに破棄する必 要があり、これもいくつかパターンがある。 RPからログアウトしたとき • RP上のTokenを破棄しOPへ失効を通知 OPで認可が取り消されたとき • OPからの通知 (Back-Channel Logout等) を受けて破棄 RPのユースケース依存 • ユーザー識別⼦など、RPセッションに直接依存しない形でAccess Tokenを保管してい る場合は、Access Tokenを破棄するタイミングは無数にある 63 RPのTokenを破棄するタイミング
64. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 Access TokenやRefresh Tokenの保持パターンは、非同期のリソースアクセスのようにユーザー に 最新のToken紐づけるなど、RPのサービス要件によって様々である。 ここでは、その中の一つのパターンとして、ユーザーがログインしている間だけリソースアクセスが必 要な「セッションとTokenを紐付ける」パターンを紹介する。 64 RPセッション にTokenを紐づけるパターン RP RPセッション OP Refresh Token Access Token RS(UserInfoなど)
65. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 RPセッションにAcess Tokenを保管している場合には、RPのログアウト操作でセッション が閉じる際に、保管しているTokenを破棄する必要がある。 このタイミングでToken破棄するのに利⽤できる仕様としてはToken Revocation (RFC 7009)がある。 RP上のTokenを破棄するタイミング: RPからログアウトしたとき OP user1の認可した RP情報 RP1認可情報 token1 RP1 user1のtoken1 1.ログアウト操作 2.revocation 65
66. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 OP側でセッションの終了やRPへの認可が取り消された際に、OPがRPへのイベント通知に 対応している場合があります。この際にRPはポリシーに応じてTokenを破棄します。イベ ント通知には以下のようないくつかの仕様があります。 • OpenID Connect Back-Channel Logout 1.0 • Shared Signals and Events (SSE) • OpenID Provider Commands 1.0 - draft 01 66 RP上のTokenを破棄するタイミング: OPで認可が取り消されたとき OP user1の認可した RP情報 RP1認可情報 token1 RP1 user1のtoken1 1.認可取り消し操作 2.認可取り消し通知
67. Copyright OpenID Foundation Japan - All Rights Reserved. アクセストークン等の保持とセッションの関連 RPのセッションとは独⽴してTokenを管理する場合、破棄のタイミングはアプリケーショ ンとしての機能や設計に依存する。例えば以下のようなケースが考えられる。 タスク完了による⾃動破棄 • ユースケース： 連絡先インポートなどのような単発の処理 • 破棄タイミング： インポートなど特定の処理が完了した時 ユーザー操作による連携解除 • ユースケース： データ同期などのような継続的なデータ連携 • 破棄タイミング： ユーザーが設定画⾯で解除した時 67 RP上のTokenを破棄するタイミング: RPのユースケース依存
68. Copyright OpenID Foundation Japan - All Rights Reserved. OP のセッションと RP のセッションを連動させる場合 68 2. OAuth/OpenID Connectにおけるセッション管理
69. Copyright OpenID Foundation Japan - All Rights Reserved. RP ごとに異なるユーザーとしてログインした状態になる ① あるブラウザで RP-1 にアクセス ② OpenID Connect により OP 経由で RP-1 にユーザー 1 としてログイン   → OP 上でも RP-1 上でもユーザー 1 としてログインしている状態 セッションが連動していないとどうなるのか 69
70. Copyright OpenID Foundation Japan - All Rights Reserved. RP ごとに異なるユーザーとしてログインした状態になる ③ 何らかの理由で OP からログアウト   → OP 上では未ログイン、RP-1 上ではユーザー 1 としてログイン中 セッションが連動していないとどうなるのか 70
71. Copyright OpenID Foundation Japan - All Rights Reserved. RP ごとに異なるユーザーとしてログインした状態になる ④ 同じブラウザで RP-2 にアクセス ⑤ OpenID Connect により OP 経由で RP-2 にユーザー 2 としてログイン   → OP 上でも RP-2 上でもユーザー 2 としてログインしている状態   → ただし、RP-1 上ではユーザー 1 としてログインしたまま セッションが連動していないとどうなるのか 71
72. Copyright OpenID Foundation Japan - All Rights Reserved. 理由① ユーザー体験 (UX) が悪い • 同じ事業者のサービス (例: Excel と PowerPoint) で別ユーザーになる • ID 連携しているサービスの数だけアカウント切り替えが必要で、⼿間 ※ 常にセッションが連動している⽅が良いとは限らない • SNS のサービスごとに、本名と趣味⽤とで別アカウントを利⽤する場合など • 提供するサービスの性質に合わせた設計が必要 セッションが連動していないと何が困るのか 72
73. Copyright OpenID Foundation Japan - All Rights Reserved. 理由② セキュリティ上のリスクがある • 共⽤ PC でのログアウト忘れで、他者の情報が⾒えてしまう • 情シス担当者が、特権アカウントと⽇常業務⽤のアカウントを切り替える • 特権アカウントによる誤操作に繋がるリスクがある • 社内利⽤のアカウントと、顧客サポート⽤のアカウントを切り替える • 顧客環境での誤操作に繋がるリスクがある セッションが連動していないと何が困るのか 73
74. Copyright OpenID Foundation Japan - All Rights Reserved. その他に考えられるケース • OP でアカウント侵害がなされた際に RP からログアウトさせる等したい • OP での規約変更に合わせて、全ての RP 含めログアウトさせたい • OP と RP を同⼀事業者が提供する前提 • OP のアカウントが削除された後に、RP を使い続けられないようにしたい • OP のアカウント削除を契機に RP のセッションを切ることが必要 セッションが連動していないと何が困るのか 74
75. Copyright OpenID Foundation Japan - All Rights Reserved. セッションを連動させるための技術仕様 • OpenID Connect Front-Channel Logout 1.0 • OP でのログアウトを Front-Channel 経由で RP に連携する • OP 起点。Cookie などセッション状態を利⽤しやすく、実装が単純になりやすい • OpenID Connect Back-Channel Logout 1.0 • OP でのログアウトを Back-Channel 経由で RP に連携する • OP 起点。RP のブラウザセッションがアクティブである必要がなく、信頼性が⾼い • OpenID Connect RP-Initiated Logout 1.0 • RP でのログアウト時に OP のログアウト URL を踏ませる • RP 起点。明⽰的なログアウト操作を⾏う場合に利⽤できる • OpenID Connect Session Management 1.0 • RP が OP のセッション状態に変更があったか確認する • RP 起点。OP からのログアウトが⾃動で反映される 技術的にどういった実現⽅法があるのか 75
76. Copyright OpenID Foundation Japan - All Rights Reserved. セッションの連動以外の要素を含む技術仕様 • OpenID Provider Commands 1.0 • OP が RP に「コマンド」を送信する • コマンドにより、RP に対してアカウントの停⽌などを要求できる • OpenID Shared Signals and Events Framework 1.0 • OP と RP の間で主体に関するイベントを相互に送受信できる • 例えば「OP のアカウントが乗っ取られたとき、OP から RP にそのことを通知し、RP のアカ ウントを無効化する」などの⽤途で利⽤できる 技術的にどういった実現⽅法があるのか 76
77. Copyright OpenID Foundation Japan - All Rights Reserved. 仕様の状態 Final (2022/09/12) https://openid.net/specs/openid-connect-frontchannel-1_0.html 技術的な概要 • RP はクライアント情報の登録時に OP に「ログアウト⽤ URL」を登録する • ログアウト⽤の iframe を OP の画⾯上に描画する • <iframe src="事前に登録したログアウト⽤ URL"> • これにより RP のログアウト⽤ URL に GET リクエストが送られる OpenID Connect Front-Channel Logout 1.0 77
78. Copyright OpenID Foundation Japan - All Rights Reserved. 技術的なポイント • RP が OP に登録するログアウト⽤ URL のドメイン、ポート、スキームは、 登録済みのリダイレクト URI の値と⼀致していなければならない (MUST) • OP が、iframe を描画すべき「ログイン中の RP のリスト」を知る⼿段が必要 • "visited sites" cookie が利⽤される場合がある • OP から RP へのリダイレクト時に、session_id に加えて visited_sites のような cookie に RP の識別⼦を⼊れておく • OP のサイトから（異なるドメインの）RP のサイトにアクセスさせるので、 ブラウザによる 3rd Party コンテンツへのアクセス制限で動かない場合がある • ブラウザのクッキーを直接削除するなど、OP が関知しない形で セッションが無効化された場合には、通知が届かない可能性がある OpenID Connect Front-Channel Logout 1.0 78
79. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect Back-Channel Logout 1.0 79 仕様の状態 Final (2023/12/15) https://openid.net/specs/openid-connect-backchannel-1_0.html 技術的な概要 • RP は OP に「バックチャネルログアウト URI」を登録する • OP は RP のログアウト URI にログアウトトークンを POST する • リクエストを受けた RP はトークンを検証したのちにセッションを破棄する
80. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect Back-Channel Logout 1.0 80 技術的なポイント • ログアウトトークンは iss や sub などを含む JWT • ログアウトするセッションに対して、offline_access プロパティを 指定せずに発⾏されたリフレッシュトークンは失効させるべき • offline_access: OIDC Core で定義される、オフラインアクセスを要求するための scope • offline_access プロパティを指定して発⾏されたリフレッシュトークンは通常、失効させる べきではない • ブラウザのクッキーを直接削除するなど、OP が関知しない形で セッションが無効化された場合には、通知が届かない可能性がある
81. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect RP-Initiated Logout 1.0 81 仕様の状態 Final (2022/09/12) https://openid.net/specs/openid-connect-rpinitiated-1_0.html 技術的な概要 • RP は End-User を OP の Logout Endpoint に送る • ログアウト後は、必要に応じて RP にリダイレクトできる
82. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect RP-Initiated Logout 1.0 82 技術的なポイント • RP が OP の Logout Endpoint を知るためには Discovery などを利⽤できる • RP が OP にログアウトを要求している End-User を伝えるために ID トークンを 送ることが推奨される (RECOMMENDED) • RP はログアウト後に特定の URI へリダイレクトさせることを要求できる • Back-Channel Logout などと併⽤する場合、ログアウト後のリダイレクトより前 に Back-Channel Logout などの処理が⾏われなければならない
83. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect Session Management 1.0 83 仕様の状態 Final (2022/09/12) https://openid.net/specs/openid-connect-session-1_0.html 技術的な概要 • OP は ID トークン発⾏時に session_state というパラメータを付与する • session_state: ログイン状態が変化すると値が変わる⽂字列 • RP は session_state と iframe、postMessage を利⽤して、定期的に OP に セッション状態の変更を確認する • OP 側でセッション状態に変化があれば、RP に通知され、RP は現在のセッ ションを終了するなどの対応を取ることができる
84. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connect Session Management 1.0 84 技術的なポイント • OP は ID トークン発⾏時に session_state というパラメータを付与する • RP の画⾯上には 2 つの iframe が描画される • RP iframe • OP iframe に対して postMessage を送信する • postMessage で送るデータには client_id と session_state を含む • OP iframe • OP の URL (check_session_iframe) を指定する • RP iframe から送られた情報をもとに、状態を再計算する • セッション状態の変化の有無を postMessage で返信する
85. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Provider Commands 1.0 85 仕様の状態 Draft 00 (2025/03/26) https://openid.net/specs/openid-provider-commands-1_0.html 技術的な概要 • OP が RP に「コマンド」を送信する • OP が RP のアカウントの停⽌、有効化、削除などを⾏える • OP が RP に unauthorize を要求すると RP のセッションが破棄される
86. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Provider Commands 1.0 86 技術的なポイント • OP が RP のコマンド URI にコマンドトークンを POST する • コマンドトークンは iss, sub, command などを含む JWT • アカウントコマンドは Lifecycle コマンドと Unauthorize コマンドに⼤別される • Lifecycle: ⼀時停⽌や削除など、アカウントの状態に関するもの • Unauthorize: RP に対して前回の OIDC ログインを取り消させる • ID トークンが悪意のある⼈物に付与された疑いがある場合や、ユーザーのデバイスが 侵害された可能性がある場合に使⽤ • RP は sub の全てのセッションを無効化しなければならない • RP は sub の全ての認可を取り消さなければならない • テナント単位で操作するテナントコマンドも定義されている
87. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Shared Signals Framework Specification 1.0 87 仕様の状態 Draft 22 (2025/05/15) https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html 技術的な概要 • Subject Principal に関するイベントを送受信する • 例えば「IdP のアカウントが乗っ取られたとき、IdP から RP にそのことを通 知し、RP のアカウントを無効化する」などの⽤途で利⽤できる • Security Event Token (SET) という形式の JWT をやり取りする
88. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Shared Signals Framework Specification 1.0 88 技術的なポイント • イベントの内容は CAEP および RISC という仕様で定義されている • CAEP (OpenID Continuous Access Evaluation Profile 1.0) • セッション取消や資格情報の変更、アクセス環境の変更などを定義 • RISC (OpenID RISC Profile Specification 1.0) • Risk Incident Sharing and Coordination の略 • アカウントの削除、無効化、資格情報の侵害などを定義 • 送受信をするエンティティは Transmitter/Receiver と呼称 • IdP → RP, RP → IdP, IdP → IdP などどれもありえる • ブラウザのクッキーを直接削除するなど、Transmitter が関知しない形で セッションが無効化された場合には、通知が届かない可能性がある
89. Copyright OpenID Foundation Japan - All Rights Reserved. 3. ユーザーアカウント削除時の処理 89
90. Copyright OpenID Foundation Japan - All Rights Reserved. 登壇者紹介 私自身もまだまだ勉強中です。 本資料が皆さんのID理解の一助になれたらと思います 那須 楓⾹ TOPPANエッジ 自社ID製品の導入や保守・運用業務に携わる中で、ま た、本活動を通じて、IDに関する知識を日々深めており ます。 佐藤 澪花 野村総合研究所
91. Copyright OpenID Foundation Japan - All Rights Reserved. 1. 本章の想定読者 • OAuthやOIDCの基礎部分を理解しているが、応⽤は踏み切れていない • そのため具体的な設計ではなく、技術の概念を伝える内容とする • OIDF-Jの⼈材育成推進WG 技術SWGにて作成した 2024年度の中間活動報告を⼀読 している • ビジネス、技術関係なくデジタルアイデンティティに携わっている 91 本章の読者については以下を想定
92. Copyright OpenID Foundation Japan - All Rights Reserved. ⽬的 ユーザーアカウントが削除された場合のユースケースを共有し、OAuth/OIDCのそれぞれに おいてユーザーアカウントが削除された場合の挙動についてまとめる。 背景 ユーザーアカウントが何らかの理由で削除や連携解除された場合の挙動を理解したいとい う思いがあり、またアカウント削除/連携解除を怠ることでセキュリティリスクが⾼まると 考えたため、本章の資料を作成することとした。 92 2. 本章の背景と⽬的
93. Copyright OpenID Foundation Japan - All Rights Reserved. アカウント削除/連携解除する場合のケース 93 3. ユーザーアカウント削除時の処理
94. Copyright OpenID Foundation Japan - All Rights Reserved. 例：ユーザーは印刷サービスとGoogleそれぞれのアカウントがあり、連携済み   （OAuthのケース） Aさんの
 アカウント
 アカウント作成済み 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 アカウント作成済み 
 連携済み 
 3.アカウント削除/連携解除する場合のケース 94
95. Copyright OpenID Foundation Japan - All Rights Reserved. 例：ユーザーは印刷サービスとGoogleそれぞれのアカウントがあり、連携済み 以下の3ケースについて、それぞれの挙動を後述する Aさんの アカウント アカウント作成済み 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 アカウント作成済み 
 連携済み 
 Googleのアカウントを削 除したら？（2）
 印刷サービスのアカウントを 削除したら？（1）
 印刷サービスとGoogleの連携を 解除したら？（3）
 3.アカウント削除/連携解除する場合のケース 95
96. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（1/6） Aさんの
 アカウント
 アカウント作成済み 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 アカウント作成済み 
 印刷サービスのアカウントを 削除したら？（1） 連携済み 
 3.アカウント削除/連携解除する場合のケース 96
97. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（2/6） Aさんの アカウント ①印刷サービスのアカウントを 削除してください resource owner (ユーザー) client (印刷サービス ) authorization server 
 (Google) 
 Aさんの アカウント 印刷サービスID 削除の確認 印刷サービスのIDを削除しますか？ 削除 戻る 3.アカウント削除/連携解除する場合のケース 97
98. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（3/6） このとき、クライアントや認可サーバではどのような対応をすべきか Aさんの
 アカウント
 ①印刷サービスのアカウントを 削除してください 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 アカウント削除に伴い、 
 何を実施すればよいか 
 Googleのアカウントは 
 どうなるのか
 Googleとの連携は
 どうするのか
 連携済み
 3.アカウント削除/連携解除する場合のケース 98
99. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（4/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 ②連携を解除してください 
 ①印刷サービスのアカウントを 削除してください 
 3.アカウント削除/連携解除する場合のケース 99
100. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（5/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 ②連携を解除してください 
 ②’アカウント 
 を削除してください 
 ①印刷サービスのアカウントを 削除してください 
 3.アカウント削除/連携解除する場合のケース 100
101. Copyright OpenID Foundation Japan - All Rights Reserved. （1）印刷サービスのアカウントを削除（6/6） Aさんの アカウント resource owner 
 (ユーザー) 
 client (印刷サービス ) authorization server 
 (Google) 
 Aさんの アカウント ②連携を解除してください Googleのアカウントは残る 
 ②’アカウント
 を削除してください 
 ①印刷サービスのアカウントを 削除してください 
 3.アカウント削除/連携解除する場合のケース 101
102. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（1/6） Aさんの
 アカウント
 アカウント作成済み 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 アカウント作成済み 
 連携済み Googleのアカウントを削 除したら？（2）
 3.アカウント削除/連携解除する場合のケース 102
103. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（2/6） Aさんの
 アカウント
 ①Googleのアカウントを 削除してください resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの アカウント Google アカウントの削除 
 はい、このGoogle アカウントとアカ ウントに関連付けられているすべ てのデータを完全に削除します。 
 アカウントを削除
 3.アカウント削除/連携解除する場合のケース 103
104. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（3/6） このとき、クライアントや認可サーバではどのような対応をすべきか Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client (印刷サービス ) authorization server 
 (Google) 
 Aさんの アカウント ①Googleのアカウントを 
 削除してください 
 
 印刷サービスのアカウントは どうなるのか
 アカウント削除に伴い、 
 何を実施すればよいか 
 印刷サービスとの 連携はどうするのか 連携済み
 3.アカウント削除/連携解除する場合のケース 104
105. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（4/6） Aさんの アカウント resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 Aさんの
 アカウント
 ②連携を解除します 
 ①Googleのアカウントを 
 削除してください 
 
 3.アカウント削除/連携解除する場合のケース 105 authorization server 
 (Google) 

106. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（5/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 Aさんの
 アカウント
 ②連携を解除します 
 ①Googleのアカウントを 
 削除してください 
 
 ②’アカウント 
 を削除してください 
 3.アカウント削除/連携解除する場合のケース 106 authorization server 
 (Google) 

107. Copyright OpenID Foundation Japan - All Rights Reserved. （2）Googleのアカウントを削除（6/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 Aさんの
 アカウント
 ②連携を解除します 
 ①Googleのアカウントを 
 削除してください 
 
 ②’アカウント
 を削除してください 
 印刷サービスのアカウントは残る ※
 ※Googleのアカウントを利用して、 
 　印刷サービスのアカウントが作成されていた場合、　 
 　印刷サービス側にアカウントは残らないケースもある。(サービスによる) 
 3.アカウント削除/連携解除する場合のケース 107 authorization server 
 (Google) 

108. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（1/6） Aさんの
 アカウント
 アカウント作成済み 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 Aさんの
 アカウント
 アカウント作成済み 
 連携済み 
 印刷サービスとGoogleの連携を 解除したら？（3）
 3.アカウント削除/連携解除する場合のケース 108 authorization server 
 (Google) 

109. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（2/6） Aさんの
 アカウント
 ①印刷サービスとの連携を 
 解除してください 
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 印刷サービス との接続を管理する 
 印刷サービス と Google に付与したア クセス権を削除できます 印刷サービス との接続をす べて削除しますか？ ＞ 3.アカウント削除/連携解除する場合のケース 109
110. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（3/6） このとき、クライアントや認可サーバではどのような対応をすべきか Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 Aさんの
 アカウント
 ①印刷サービスとの連携を 
 解除してください 
 
 
 権限の解除に伴い、 
 印刷サービスのアカウントは どうなるのか
 Googleのアカウントはど うなるのか
 連携済み解除に伴い、 
 何を実施すればよいか 
 連携済み
 3.アカウント削除/連携解除する場合のケース 110 authorization server 
 (Google) 

111. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（4/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 ②連携を解除します 
 ①印刷サービスとの連携を 
 解除してください 
 
 
 
 3.アカウント削除/連携解除する場合のケース 111
112. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（5/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの
 アカウント
 ②連携を解除します 
 印刷サービスのアカウントは残る 
 ①印刷サービスとの連携を 
 解除してください 
 
 3.アカウント削除/連携解除する場合のケース 112
113. Copyright OpenID Foundation Japan - All Rights Reserved. （3）印刷サービスとGoogleの連携解除（6/6） Aさんの
 アカウント
 resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 Aさんの アカウント ②連携を解除します 
 印刷サービスのアカウントは残る 
 Googleのアカウントは残る 
 ①印刷サービスとの連携を 
 解除してください 
 
 3.アカウント削除/連携解除する場合のケース 113
114. Copyright OpenID Foundation Japan - All Rights Reserved. アカウントが削除されない場合のリスク 114 3. ユーザーアカウント削除時の処理
115. Copyright OpenID Foundation Japan - All Rights Reserved. ▪OAuthの場合（一般的な可能性を例示） 
 • アカウント乗っ取りや個人情報漏洩 
 • アカウント保持による金銭の発生 
 • 個人情報保持による規則違反 
 • 認可サーバ側からの再連携による意図しないアカウント再登録＆再連携 
 • 認可サーバ側にアクセストークン・リフレッシュトークン※が残っている場合の、APIリクエスト試行 
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ※トークンの説明は後述にて記載 
 115 4.アカウントが削除されない場合のリスク
116. Copyright OpenID Foundation Japan - All Rights Reserved. ▪OIDCの場合（一般的な可能性を例示） 
 • 認証失敗によるサービス利用の障害 
 • アカウント乗っ取りや個人情報漏洩 
 • 個人情報保持による規則違反（GDPR） 
 • OP側からの再連携による意図しないRP側のアカウント再登録＆再連携 
 • OP側にトークンが残っている場合の、APIリクエスト試行 
 116 4.アカウントが削除されない場合のリスク
117. Copyright OpenID Foundation Japan - All Rights Reserved. 【OAuth】クライアント/認可サーバ側の アカウントが削除された場合の挙動 117 3. ユーザーアカウント削除時の処理
118. Copyright OpenID Foundation Japan - All Rights Reserved. ◆resource owner(ユーザー) • 保護されたリソースへのアクセスを許可する存在 ◆client(クライアント) • リソースオーナーの認可を得て, リソースオーナーの代理として保護されたリソースに対するリ クエストを⾏うアプリケーション ◆authorization server(認可サーバ) • リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, アクセストークンを クライアントに発⾏するサーバー ▪登場⼈物 118 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動
119. Copyright OpenID Foundation Japan - All Rights Reserved. ◆アクセストークン • 保護されたリソースにアクセスするために使⽤されるクレデンシャル(資格) • クライアントに対して発⾏される認可を表す⽂字列 • 有効期間：短期的（クライアントに有効期限を伝える必要有） ◆リフレッシュトークン • アクセストークンを取得するために使⽤されるクレデンシャル(資格) • 認可サーバーによってクライアントに対して発⾏される • 有効期間：⻑期的（追加のアクセストークンを要求するために使⽤するため） ▪トークンの種類 119 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動
120. Copyright OpenID Foundation Japan - All Rights Reserved. ◆RFC7009 OAuth 2.0 Token Revocation • RFC7009はOAuth 2.0で認可サーバが発⾏したトークンをクライアント駆動で無効化するための標 準仕様を定めている。 • クライアントは、ユーザによるログアウト、ID変更、アプリケーションのアンインストールなどを 契機として認可サーバにトークン無効化を要求する。 POST /revoke HTTP/1.1 
 Host: server.example.com 
 Content-Type: application/x-www-form-urlencoded 
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
 
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token 
 Revocation Request 
 HTTP/1.1 200 OK 
 Revocation Response 
 Revocation Requestにおいて、クライアントは認証クレデンシャルを含んでも良い
 クライアント認証の仕様は、RFC6749　Section 2.3で規定される
 パラメータ
 アクセストークン
 リフレッシュトークン
 access_token
 無効化対象
 無効化してもよい
 refresh_token
 無効化すべき
 無効化対象
 1 2 0 ▪アカウント削除において関連する標準規格 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 token（必須）
 　　クライアントが無効化したいトークン
 
 token_type_hint（任意）
 　　無効化のために送信されるトークンタイプのヒント.
 　　認可サーバが効率的にトークンを検索するために指定する.
 　　RFC7009は下記２つのパラメータを定義している.
 パラメータ
 アクセストークン
 リフレッシュトークン
 access_token
 無効化対象
 無効化してもよい
 refresh_token
 無効化すべき
 無効化対象

121. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの アカウント ①アカウント削除依頼 
 resource owner 
 (ユーザー) 
 例：クライアントアカウント削除に基づきトークンを失効する場合(1/8) authorization server 
 (Google) 
 トークン
 121 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 client 
 (印刷サービス) 

122. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 ②アカウント削除 
 122 トークン
 例：クライアントアカウント削除に基づきトークンを失効する場合(2/8) resource owner 
 (ユーザー) 
 authorization server 
 (Google) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ①アカウント削除依頼 
 client 
 (印刷サービス) 

123. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 ②アカウント削除 
 ③トークン失効リクエスト 
 123 例：クライアントアカウント削除に基づきトークンを失効する場合(3/8) トークン
 resource owner 
 (ユーザー) 
 authorization server 
 (Google) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 リクエスト内容
 POST /revoke HTTP/1.1 
 Host: server.example.com 
 Content-Type: application/x-www-form-urlencoded 
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token 
 
 
 ①アカウント削除依頼 
 client 
 (印刷サービス) 

124. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 リクエスト内容
 POST /revoke HTTP/1.1 
 Host: server.example.com 
 Content-Type: application/x-www-form-urlencoded 
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token 
 
 
 token(必須)
 クライアントが失効させたいトークン 
 token_type_hint(任意) 
 失効させるトークン種類のヒント 
 検索を最適化するように支援 
 124 トークン
 例：クライアントアカウント削除に基づきトークンを失効する場合(4/8) resource owner 
 (ユーザー) 
 client 
 (印刷サービス) 
 authorization server 
 (Google) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ①アカウント削除依頼 
 ②アカウント削除 
 ③トークン失効リクエスト 

125. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 ?
 125 例：クライアントアカウント削除に基づきトークンを失効する場合(5/8) resource owner 
 (ユーザー) 
 authorization server 
 (Google) 
 client 
 (印刷サービス) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ④トークンの正当性確認 ①アカウント削除依頼 
 ②アカウント削除 
 ③トークン失効リクエスト 
 トークン

126. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 ②アカウント削除 
 ※エラーの場合 
 ⑤リクエスト拒否 
 リクエスト内容
 POST /revoke HTTP/1.1 
 Host: server.example.com 
 Content-Type: application/x-www-form-urlencoded 
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token 
 
 
 不一致 
 126 例：クライアントアカウント削除に基づきトークンを失効する場合(6/8) resource owner 
 (ユーザー) 
 ④トークンの正当性確認 authorization server 
 (Google) 
 client 
 (印刷サービス) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ①アカウント削除依頼 
 ③トークン失効リクエスト 
 トークン

127. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 リクエスト内容
 POST /revoke HTTP/1.1 
 Host: server.example.com 
 Content-Type: application/x-www-form-urlencoded 
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token 
 
 
 ※正常完了の場合 
 ⑤トークン失効 
 一致 127 例：クライアントアカウント削除に基づきトークンを失効する場合(7/8) client 
 (印刷サービス) 
 resource owner 
 (ユーザー) 
 authorization server 
 (Google) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ④トークンの正当性確認 ②アカウント削除 
 ①アカウント削除依頼 
 ③トークン失効リクエスト 
 トークン

128. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの
 アカウント
 ⑥失効完了 
 HTTPステータスコード：200 
 128 例：クライアントアカウント削除に基づきトークンを失効する場合(8/8) ※正常完了の場合 
 ⑤トークン失効
 authorization server 
 (Google) 
 resource owner 
 (ユーザー) 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 ④トークンの正当性確認 client 
 (印刷サービス) 
 ②アカウント削除 
 ①アカウント削除依頼 
 ③トークン失効リクエスト 
 トークン

129. Copyright OpenID Foundation Japan - All Rights Reserved. User Agent
 AS
 Client
 アカウント削除 依頼
 トークン 
 使用禁止 
 Clientアカウント削除/トー クン失効
 クライアント情報の検証 
 トークンの正当性確認 
 ※エラーの場合 
 リクエスト拒否 
 ※成功の場合 
 トークン失効 
 HTTP 200(失効完了) 
 トークン失効依頼 
 HTTPSであることを必ず確認し なければならない(MUST)
 129 アカウント削除 
 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動 クライアントのアカウントが削除された場合のシーケンス
130. Copyright OpenID Foundation Japan - All Rights Reserved. User Agent
 AS
 Client
 アカウント削除 ASアカウント削除/ トークン失効 アカウントに紐づく トークンの失効 HTTP 200 トークン送信 クライアントがアカウントを削除 しているのを感知せずにトーク ンを送信 エラーではなくHTTP 200で連携される ※クライアントがエラーレスポンスを適切 に処理できないため 認可サーバ側には影響なし 認可サーバのアカウントが削除された場合のシーケンス 5.【OAuth】クライアント/認可サーバ側のアカウントが削除された場合の挙動
131. Copyright OpenID Foundation Japan - All Rights Reserved. 【OpenID Connect】RP/OP側の アカウントが削除された場合の挙動 131 3. ユーザーアカウント削除時の処理
132. Copyright OpenID Foundation Japan - All Rights Reserved. ◆登場⼈物 132 ◆UserAgent(ユーザー) • サービス利⽤者 ◆RP(Relying Party) • ユーザーの認証情報を利⽤するクライアント ◆OP(OpenID Provider) • ユーザー認証とトークン発⾏を⾏う認可サーバ 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
133. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの 
 アカウント 
 ①アカウント削除要求 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） 
 例：RPのアカウント削除に基づきトークンを無効化する場合（1/6） トークン
 トークン
 133 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
134. Copyright OpenID Foundation Japan - All Rights Reserved. ①アカウント削除要求 
 Aさんの 
 アカウント 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） 
 例：RPのアカウント削除に基づきトークンを無効化する場合 （2/6） トークン
 トークン
 ②アカウント削除 
 134 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
135. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの 
 アカウント 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） 
 例：RPのアカウント削除に基づきトークンを無効化する場合 （3/6） トークン
 トークン
 ②アカウント削除 
 ③トークン無効化要求 
 トークン
 リクエスト内容
 
 POST /revoke HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
 token(必須) 
 RPが無効化させたいトークン 
 token_type_hint(任意) 
 無効化させるトークン種類のヒント 
 検索を最適化するように支援 
 135 ①アカウント削除要求 
 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
136. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの 
 アカウント 
 ①アカウント削除要求 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） 
 例：RPのアカウント削除に基づきトークンを無効化する場合 （4/6） トークン
 ②アカウント削除 
 ③トークン無効化要求 
 トークン リクエスト内容
 
 POST /revoke HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
 ④トークンの正当性確認 
 トークン
 トークン
 or
 ：正当ならトークンを無効化 
 ：不当ならエラー判定 
 一致
 不一致
 136 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
137. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの 
 アカウント 
 ①アカウント削除要求 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） 
 例：RPのアカウント削除に基づきトークンを無効化する場合 （5/6） トークン
 ②アカウント削除 
 ③トークン無効化要求 
 トークン ④トークンの正当性確認 
 トークン
 トークン
 or
 ⑤トークン無効化応答 
 　(HTTP 200 OK) 
 ⑤’トークン無効化応答 
 　(HTTP 400(Bad Request)) 
 無効化対象のトークンは、アクセストークンまたはリフレッシュトークンのみ
 ※OIDCではトークンとしてIDトークンが存在するが無効化の対象外。
 　 IDトークンはRPの認証時にのみ使用されるため、認証後はRP側で即時に破棄される
 137 ：正当ならトークンを無効化 
 ：不当ならエラー判定 
 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
138. Copyright OpenID Foundation Japan - All Rights Reserved. Aさんの 
 アカウント 
 ①アカウント削除要求 
 ②アカウント削除 
 ユーザー（Aさん） 
 印刷サービス 
 （RP）
 Google（OP） ③トークン無効化要求 
 例：RPのアカウント削除に基づきトークンを無効化する場合 （6/6） ④トークンの正当性確認 
 トークン
 トークン
 トークン
 or ⑤トークン無効化応答 
 　(HTTP 200OK) 
 ⑤’トークン無効化応答 
 　(HTTP 400(Bad Request)) 
 　※⑥への遷移無し 
 トークン ⑥トークン無効化 
 138 ：正当ならトークンを無効化 
 ：不当ならエラー判定 
 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動
139. Copyright OpenID Foundation Japan - All Rights Reserved. User Agent
 OP
 RP
 アカウント削除 
 アカウント削除 
 トークン無効化要求 w/トークン 
 トークン無効化応答 HTTP 200 
 トークン無効化 
 トークン無効化 
 トークンはアクセストークンまたはリフレッシュ トークンを指定する
 ※RFC7009 OAuth 2.0 Token　RevocationSection 3.1. 
 139 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動 RP側のアカウントが削除された場合のシーケンス
140. Copyright OpenID Foundation Japan - All Rights Reserved. User Agent
 OP
 RP
 アカウント削除（またはRP連携解除） 
 アカウント削除（またはRP連携解除）と共に 
 紐づくトークンの無効化 
 Userinfo応答 HTTP 400 
 Userinfo要求 w/アクセストークン 
 RPがアカウントを削除したことを感 知せずにトークンを送信
 トークン応答 HTTP 400 
 トークン要求 w/リフレッシュトークン 
 アクセストークン検証 
 リフレッシュトークン検証 
 ～ ～ ～ ～ ～ ～ ～ ～ OPではトークンが不当と判断され
 HTTP 400を応答
 ※OpenID Connect Core 1.0 Section 5.3.3. 
 OPではトークンが不当と判断され
 HTTP 400を応答
 ※OpenID Connect Core 1.0 Section 3.1.3.4. 
 140 6.【OpenID Connect】RP/OP側のアカウントが削除された場合の挙動 OP側のアカウントが削除された場合のシーケンス
141. Copyright OpenID Foundation Japan - All Rights Reserved. 4. OpenID Connectを活用した身元確認 141
142. Copyright OpenID Foundation Japan - All Rights Reserved. 宮崎県出身で猫と過ごしながら、普段は てらら というハンド ルネームで活動しております。 より多くの方々に自分の携わったデジタル IDを活用していた だける世界を夢見ています。 登壇者紹介 寺原 歩 フリー株式会社
143. Copyright OpenID Foundation Japan - All Rights Reserved. 本章の想定読者 • OpenID Connectの基礎部分を理解している。⾝元確認‧当⼈認証を考えながら設 計するにあたり、Relying Party視点の⾝元確認について課題を感じている。 143 本章の読者については以下を想定
144. Copyright OpenID Foundation Japan - All Rights Reserved. OpenID Connectにおけるid_tokenは OpenID Provider が 実施した認証結果を Claim として ID Token に含めて Relying Party に渡す。 この時、Claimに含まれるのは OpenID Provider の提⽰するエンドユーザーの属 性情報であり、それが何を持って検証済みであるか、どのように⾝元確認された ものであるかの情報は含まれていない。 OpenID ConnectのID Tokenについて 144 Aさんの姓名
 ユーザー
 OP
 RP
 ①アカウント作成
 Aさんの
 身元確認に必要なエビデンス情報 
 （免許証を提示）
 ③ID Token
 （連携フローは割愛）
 ②RPへのID連携要求 （連携フローは割愛）
 何を持って検証済みとし たのか分からない。 
 出典: https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#Authentication
145. Copyright OpenID Foundation Japan - All Rights Reserved. OIDC4IDA とは エンドユーザーはWebService上でサインアップする際にユーザー⾃⾝の属性情 報を登録する。この登録情報はユーザーの⾃⼰主張によって登録された属性で あり、検証された情報ではないため法的な要件では利⽤できない。 OpenID Connect 仕様 を拡張し、エンドユーザーの属性情報に “検証に利⽤した プロセス情報” 、 “検証のエビデンス” を載せることで RelyingParty が強⼒な保 証を必要とするユースケースに対応することを⽬的とする。 “OpenID Connect for Identity Assurance” を指す。 { "verified_claims": { "verification": { "trust_framework": "eidas", "assurance_level": "substantial" }, "claims": { "given_name": "Max", "family_name": "Meier", "birthdate": "1956-01-28", "place_of_birth": { "country": "DE", "locality": "Musterstadt" }, "nationalities": [ "DE" ] } } } 出典: https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html#name-notified-eid-system-eidas 145
146. Copyright OpenID Foundation Japan - All Rights Reserved. OIDC4IDA とは 策定までの略歴 出典: https://lists.openid.net/pipermail/openid-specs-ab/2019-February/007212.html eIDAS等法規制に伴い、従来の紙による署名と法的に同等となりうる、電⼦的な 本⼈確認の需要が急速に拡⼤した。 OIDCを拡張した以下のソリューション提案がなされ、策定に向けた議論が開始 された。 146
147. Copyright OpenID Foundation Japan - All Rights Reserved. OIDC4IDA とは 策定までの略歴 最終仕様が承認された際には以下の３つの仕様が承認されている。 • OpenID Connect for Identity Assurance 1.0 • OIDC4IDAにおける OIDC の使い⽅を定義 • OpenID Identity Assurance Schema Definition 1.0 • 検証済み属性、検証内容のスキーマの定義 • OpenID Connect for Identity Assurance Claims Registration 1.0 • OIDCで定義される標準Claims以外のClaims定義 2025年に OpenID Attachments 1.0 も承認された。 出典: https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID1.html https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID2.html https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID3.html https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html https://openid.net/final-openid-connect-for-identity-assurance-specifications-approved/ https://openid.net/openid-attachments-1-final-specification-approved/ 147
148. Copyright OpenID Foundation Japan - All Rights Reserved. OIDC4IDA とは 実現できること 出典: https://openid.net/wg/ekyc-ida/ - How will eKYC & IDA spec do this? “何に基づいたルールで” “どのような検証⽅法で” “いつ” “どのような組織が” 検 証したのか。またそれらを検証するために “提⽰されたエビデンスの内容” を受 け渡しすることができる。 148
149. Copyright OpenID Foundation Japan - All Rights Reserved. 受け取ったRelyingPartyは検証されたClaimsと検証されていないClaimsを区別し て利⽤でき、下記を例とした強⼒な保証レベルが求められるユースケースで利⽤ できる。 • マネーロンダリング対策 • 政府 • 健康データへのアクセス • インターネット利⽤詐欺防⽌ OIDC4IDA とは 実現できること 出典: https://openid.net/wg/ekyc-ida/ - Why is this being done as an OpenID Connect extension? https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-requirements なお、受け取ったデータを評価し、それを独⾃の法的コンテキストにマッピング するのは RP の責任である。これによって真に国際的で異なる管轄区域を跨いで identity assurance をサポートすることを意図している。 149
150. Copyright OpenID Foundation Japan - All Rights Reserved. OIDC4IDAと信頼性について OIDC4IDAのスコープについて • OIDC4IDAは検証されたClaimsの要求と提供を可能にするものであり、その完全なソリューショ ンを展開するために必要な追加の側⾯についてはスコープ外 →RPはOPから検証されたClaimsがエンドユーザーと紐づけられていることを信頼する前提 RPは提供するサービスに合わせて属性のマッピングが必要 • 例： • 2024年1⽉11⽇11時に対⾯でマイナンバーカードを⽤いて検証された名前、⽣年⽉⽇をOP から受領 • RPは携帯電話不正利⽤防⽌法の要件に合うかを確認する • 第五条⼀項イ(2)でマイナンバーカードが本⼈確認書類として認められる • 本⼈確認の⽅法は第三条⼀項イで本⼈確認書類の提⽰とされている →検証されたClaimsは携帯電話不正利⽤防⽌法のにおける本⼈確認⽅法の⼀つとして、適切な委託 関係のもとで活⽤できる可能性がある （単にClaimに依拠するだけでは要件を満たさないため注意） • IAL(Identity Assurance Level)を⽤いて判断するという⼿段もある • 申請者の⾝元確認プロセスの厳密さ⽰すレベル ⾝元確認された情報の利⽤ 出典: https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-s https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf  https://laws.e-gov.go.jp/law/417M60000008167/ 150
151. Copyright OpenID Foundation Japan - All Rights Reserved. GET /authorize? response_type=code &scope=openid%20email &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fexample.org%2Fcb &claims=%7B%22id_token%22%3A%7B%22 verified_claims%22%3A%7B%22verification %22%3A%7B%22trust_framework%22%3A null%7D%7D%7D%7D { ... "trust_frameworks_supported":[ "nist_800_63A" ], ... } OIDC4IDAと信頼性について 開始⽅法 （OP metadata） 出典: https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html#name-op-metadata OPは openid-configuration に 検証されたClaims に関する能⼒を告知する。 RPは OP の openid-configuration を参照し、利⽤可能なClaimsをリクエストに 含めることができる。 OP metadataの例 RPのリクエスト例 デコード { "id_token":{ "verified_claims":{ "verification":{ "trust_framework":null } } } } RPは scope を指定して要求することもできる。 151
152. Copyright OpenID Foundation Japan - All Rights Reserved. claims種別と使い分けについて（既存claimsとのマッピング） verified_claimsのclaims要素には、OpenID Connectの既存claims（name, birthdate等）を そのまま使えます。 違いは「検証済み」であることと、検証⽅法（verification要素）を明⽰する点 claimsの種別 1. Unverified Claims（未検証クレーム）  通常のOpenID Connectで提供されるclaims。IDプロバイダーが検証せずに提供する情報。 2. Verified Claims（検証済クレーム）  identity verificationプロセスを経て、特定の保証レベルで検証されたclaims。  例：本⼈確認書類や公的記録、電⼦署名等に基づく情報。 verified_claimsの構造 1. claims  検証済みの個⼈情報（例：given_name, family_name, birthdate, address等） 2. verification  検証プロセスの詳細（例：trust_framework, assurance_level, evidence等） ユースケース解説 出典: https://openid-foundation-japan.github.io/openid-ida-verified-claims.html 152
153. Copyright OpenID Foundation Japan - All Rights Reserved. ユースケース解説 • 使い⽅ • RP（サービス提供者）は、OpenID Connectのclaimsパラメータで verified_claimsを指定し、必要な検証済み属性（例：⽒名、⽣年⽉⽇、住所な ど）と検証⽅法（trust_frameworkやevidence等）を細かくリクエスト可能 • OP（IdP）は、検証プロセスやエビデンス情報とともに、検証済みの属性値をID トークンやUserInfoで返却 例：特定のトラストフレームワークや証明書類（運転免許証、パスポート 等）に基づく検証済み⽒名‧⽣年⽉⽇を要求 • 代表ユースケース • 教育：デジタル成績証明書、試験受験の証明やオンライン授業の⾝元確認 • ⾦融：⼝座開設、送⾦、⼝座解約時の⾝元確認 • 医療：処⽅箋発⾏の検証、オンライン薬局での患者情報の確認 verified claims（使い⽅、代表ユースケース） 出典: https://openid-foundation-japan.github.io/openid-connect-4-identity-assurance.html#name-verified-claims 出典:https://www.w3.org/TR/vc-use-cases/ 153
154. Copyright OpenID Foundation Japan - All Rights Reserved. プライバシーへの配慮 • scopeは、定義済みのclaimセットを要求するために利⽤されるが、RPへ返却 される応答では必要なデータより多くなる可能性がある。そのため、RP は必 要なエンドユーザーの claim とメタデータのみを要求することが望ましい。 • 具体例：  （タイムゾーン‧コンポーネントを含む）タイムスタンプの要求の場合で は、タイムゾーンを含んでいるため、意図せずその⼈物のロケーション情報 を提供する（している）可能性がある。これは意図せずプライバシー情報を 開⽰（提供）してしまっているとも捉えうる。  対処としては、タイムゾーンを含める特別な理由がない限り、協定世界時 (UTC：Universal Time Coordinated) で表すなどでの回避が考えられる。 Privacy Consideration 出典: https://openid-foundation-japan.github.io/openid-connect-4-identity-assurance.html#name-privacy-consideration 154
155. Copyright OpenID Foundation Japan - All Rights Reserved. 今後予定される拡張仕様 まだ Final となっていない、以下の仕様の策定が eKYC-IDA WG にて継続中 • OpenID Connect Authority claims extension • 他の⾃然⼈または法⼈に対する、⾏為権限の表現（「代理」の表現）を定 義した仕様 • 主に法⼈ユースケースにおいて、⾏為者である⾃然⼈が（法 ⼈に変わって⾏為する ） 権限を持っているか否かを表現する 、といった 使い⽅を想定 • OpenID Connect Advanced Syntax for claims (ASC) • RP が claim の要件をより具体的に指定する⽅法を定義した仕様 • 現時点では Selective Abort/Omit と Transformed Claims という 2 つの機 能が提案されている • 年齢そのものではなく”◯歳以上 (Yes/No)” を返す等 、データ最⼩化の原則を達成するための利⽤を想定 出典: https://openid.net/wg/ekyc-ida/specifications/ 155
156. Copyright OpenID Foundation Japan - All Rights Reserved. 5. OAuth/OpenID Connect セキュリティベストプラクティス 156
157. Copyright OpenID Foundation Japan - All Rights Reserved. プロフィール写真 登壇者紹介 直近のID連携プロジェクトをきっかけに認証・認可に興味を 持ちはじめました。これから学ばれる人がどこに気をつけれ ばよいのか参考になればと思って関わらせてもらいました。 157 藏⽥ 貴之 フリー株式会社
158. Copyright OpenID Foundation Japan - All Rights Reserved. ⾼まるセキュリティ要件 5. OAuth/OpenID Connect セキュリティベストプラクティス 158
159. Copyright OpenID Foundation Japan - All Rights Reserved. RFC-9700について RFC-6749, RFC-6750, RFC-6819公開以降、OAuth2.0が広く利⽤されAPI保護の標準やOpenID Connectを利⽤した連携ログインの基礎となってきた。⼀⽅で新たな課題や対策についてカ バーをする必要性もでてきている。 課題 • 絶えない脆弱性攻撃 • 初期では考えられていなかったより⾼いセキュリティ要件環境での利⽤ • Open Banking, eHealth, eGovernment, 電⼦サインなど • 想像以上に動的登録が利⽤され、セキュリティ観点の課題 • ブラウザなどの技術の変化による課題 これらの課題についてセキュリティプラクティスを⽰すのがRFC-9700 OAuth2.0を利⽤するためのセキュリティプラクティス 159
160. Copyright OpenID Foundation Japan - All Rights Reserved. RFC-9700の歴史 • RFC 6749(2012), RFC 6750(2012), RFC 6819(2013)はpublishedになる • RFC-9700のdraftは2016年に作成され、2025-01にpublishedになる • 初回は8個攻撃が登場したが、最終的に17個の攻撃と対策に整理された 160 2016年: 8個 2020年: 15個 2024年: 17個 2018年: 12個 2022年: 16個
161. Copyright OpenID Foundation Japan - All Rights Reserved. OAuth2.1でも取り上げられるセキュリティ OAuth2.0との差分として以下のようなセキュリティ対策について触れられる。 • 認可コードグラントでPKCE必須 • リダイレクトURIの⽂字列が完全⼀致をもって⽐較 • インプリシットフロー(response_type=token)の廃⽌ OAuth2.1 Authrozation Frameworkはdraft-ietf-oauth-v2-1-13で整理されており (現在draftステータス)、セキュリティ観点についての記述あり 161
162. Copyright OpenID Foundation Japan - All Rights Reserved. 攻撃者モデル 5. OAuth/OpenID Connect セキュリティベストプラクティス 162
163. Copyright OpenID Foundation Japan - All Rights Reserved. 攻撃者の特性 • A1: Web攻撃者 • A2: ネットワーク攻撃者 • A3: 認可サーバのレスポンスの盗聴 • A4: 認可サーバへのリクエストの盗聴 • A5: アクセストークンを窃取 A1,A2とA3~A5を組み合わせた攻撃について想定して、 そこから⽣じる脅威や対策について整理している。 RFC-6819で攻撃者を想定されていたが明⽰化されていたなかった。 RFC-9700では、攻撃者を次の5つのパターンに整理されてる。 163
164. Copyright OpenID Foundation Japan - All Rights Reserved. A1, A2: 最⼩限の攻撃者モデル 164 A1: Web攻撃者 ブラウザやサーバーどちらからでも認可プロトコルに参加しようとする - 広告やメールから攻撃者のURLを踏ませようとする - 連携する認可サーバになりしましてくる ※ 通信内容の盗聴や改ざんはできないという前提 A2: ネットワーク攻撃者 プロトコル参加者が通信するネットワークを完全に制御していることを利⽤した攻撃 - 通信内容の盗聴、改ざん、なりすましを⾏う - 任意のメッセージを受信させないようにする 例) インターネットサービスプロバイダー, 公衆フリーWi-FiでのARPスプーフィング, IXPにアクセスできる国家⽀援者
165. Copyright OpenID Foundation Japan - All Rights Reserved. A3 ~ A5: 強⼒な攻撃者モデル 165 A1, A2の最⼩限のモデルから更に強化されたモデル A3: 認可レスポンスを変更できないが読み取れる攻撃者 A4: 認可リクエストを変更できないが読み取れる攻撃者 A5: 認可サーバが発⾏したアクセストークンを取得できる攻撃者 A1, A2に加えてA3~A5が満たされた攻撃を想定する。 そして対策についてOAuth/OIDCの実装者が気をつける
166. Copyright OpenID Foundation Japan - All Rights Reserved. 脅威と対策 5. OAuth/OpenID Connect セキュリティベストプラクティス 166
167. Copyright OpenID Foundation Japan - All Rights Reserved. 攻撃⼀覧 • Misuse of Stolen Access Token • Credential Leakage via Referer Headers • PKCE Downgrade Attack • Insufficient Redirection URI Validation • Credential Leakage via Browser History • Mix-Up Attacks • Authorization Code Injection • Access Token Injection • Cross-Site Request Forgery • Access Token Leakage at the Resource Server • Open Reidrection • 307 Redirect • TLS Terminating Reverse Proxies • Refresh Token Protection • Client Impersonating Resource Owner • Clickjacking • Attacks on In-Browser Communication Flows 167
168. Copyright OpenID Foundation Japan - All Rights Reserved. Misuse of Stolen Access Tokens 168 認可サーバはアクセストークンが盗まれた場合の対策を⾏うべきである(SHOULD) 送信者制限アクセストークン リソースサーバは前提条件を満たさないとアクセストークン 受け付けないようにする • OAuth 2.0 Mutual-TLS Client Authentication and Certificate Bound Access Tokens [RFC-8705] • 相互TLSで認可サーバーはトークンとクライアン ト認証情報を紐づけし、リソースサーバへのリク エストでは紐づけを確認することで正しい送信者 かを判定 • OAuth 2.0 Demonstrating Proof of Possession(DPoP) [RFC-9449] • クライアントで作成する公開鍵と秘密鍵のペアを 利⽤して、認可サーバでアクセストークンと公開 を紐づける。リソースサーバへのリクエストでは 両者の紐づけ確認することで送信者を制限 クライアント 認可サーバー リソースサーバー ① DPoPヘッダーを付与した  トークンリクエスト ② DPoPと紐づいたアクセストークン ③ DPoPヘッダーとアクセス トークンを付与してリクエスト ④ DPoPの公開鍵ととアクセストーク ンの公開鍵が⼀致するか検証 DPoPを使った送信者制限する流れ
169. Copyright OpenID Foundation Japan - All Rights Reserved. Misuse of Stolen Access Tokens 169 オーディエンス制限アクセストークン アクセストークンの送信先リソースサーバを制限することで、窃取されたアクセストークンの悪⽤による被害を 極⼩化することができる。[RFC-8707] クライアント 認可サーバー リソースサーバー ① リソースサーバを指定した  トークンリクエスト ② リソースサーバと紐づいたアクセ ストークン ③ アクセストークン ④ アクセストークンに紐づくリソース と⾃⾝が同じかどうかの検証 POST /as/token.oauth2 HTTP/1.1 Host: authorization-server.example.com Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &resource=https%3A%2F%2Fcal.example.com%2F { "iss": "http://authorization-server.example.com", "sub": "__b_c", "exp": 1588420800, "scope": "calendar", "aud": "https://cal.example.com/" } ①トークンリクエスト ② jwtのアクセストークンのペイロード部分 https://cal.example.com/ https://cal.example.com/ 参考: https://speakerdeck.com/kuralab/20250620-openid-technight-mcp-oauth?slide=46
170. Copyright OpenID Foundation Japan - All Rights Reserved. 登壇者紹介 情報系初学者でわからないことだらけですが、逆に基礎の 基礎から積み上げられる機会だと思い、丁寧に習得を進め ています。 170 永⽥ 憲正 ⼤⽇本印刷株式会社 プロフィール写真
171. Copyright OpenID Foundation Japan - All Rights Reserved. Credential Leakage via Referer Headers Referer HTTP headerとは • RFC 7231や9110(HTTP Semantics)などで定義される、ターゲットURIが取得 された、リソースのURIをユーザーエージェントが特定できるようにする headerパラメータ • 分析、記録、キャッシング、CSRF対策として⽤いられる • RFC 9110において、Referer headerに機密情報が含まれる危険性について⾔ 及しており、⾮セキュアなHTTPリクエストに対してはReferer header field を送ってはならない(MUST NOT)と記載 認可リクエストURIや認可レスポンスURIの内容が、Referer HTTP headerから漏 洩する攻撃 171 リソース ターゲット https://hogehoge.com?user_id （リソースのURI） https://fugafuga.com （ターゲットURI） リソース内リンク アクセス HTTPリクエストの referer headerにリソー スURIが格納されてる
172. Copyright OpenID Foundation Japan - All Rights Reserved. Credential Leakage via Referer Headers OAuthクライアントから、認可レスポンスのcodeとstate値が漏洩するフロー 172 • 認可リクエストが成功した結果で表⽰され るページに、攻撃者のコントロール下にあ る外部ページへのリンクやサードパーティ のコンテンツが含まれている • ユーザーがそのリンクなどをクリックする • ブラウザが攻撃者のページに移動または サードパーティのコンテンツをロードし、 攻撃者は認可レスポンスURIを受け取り、 codeとstate値を抽出できる ※ここではOAuthクライアントからのReferer headerを⽤いた情報漏洩を説明したが、 OAuthサーバーの設計不備によるサーバー側からの漏洩も存在する。
173. Copyright OpenID Foundation Japan - All Rights Reserved. Credential Leakage via Referer Headers 認可レスポンスの結果として表⽰されたページや、認可エンドポイントに、外部へのリンクや サードパーティのコンテンツを含めるべきではない(SHOULD NOT) 以下は追加対策 • Referer Policy[w3c.webappsec-referrer-policy]を活⽤し、Referer headerを制限する • 認可エンドポイントからアクセストークンを払い出さず、認可コードを⽤いる • 認可コードをコンフィデンシャルクライアントかPKCEのchallengeと紐づける • 認可コードの複数回利⽤を制限 ◦ 認可コードを⼀度利⽤した後に無効化しなければならない（再利⽤禁⽌化）(MUST) ◦ ⼆回⽬の利⽤を試みた場合、⼀回⽬の利⽤時に発⾏したトークンをすべて破棄すべき である(SHOULD) • state値を⼀度利⽤したら無効化すべきである(SHOULD) • 認可レスポンスをリダイレクトの代わりにform post response modeを⽤いる [OAuth.Post] 対策 173
174. Copyright OpenID Foundation Japan - All Rights Reserved. Credential Leakage via Referer Headers • Google OAuthにおいて、攻撃者が介在しresponse_type = id_token, codeとす ることで、state、id_token、codeが漏洩する脆弱性 • リダイレクトのエラー処理時に、Referer headerのURIへリダイレクトする仕 様を利⽤ Top 10 Web Hacking Techniques of 2024においてRefererパラメータによる脆弱 性が指摘されている(8. OAuth Non-Happy Path to ATO) 174 OAuth Non-Happy Path to ATO RFC9700では、エラー処理を利⽤した脆弱性ではなく、正常系におけるコンテンツ 不備によるReferer Headerのcodeやstateの漏洩であり、異なる脆弱性である。
175. Copyright OpenID Foundation Japan - All Rights Reserved. PKCE Downgrade Attack 175 PKCEとは • 認可コードを取得するクライアントと、トークン発行を行うクライアントの同一性 を保証する仕組み • RFC7636において、「認可コード横取り攻撃」への対策として策定された仕様 • CSRFへの対策としても有効 • PKCEの詳細解説は過去の報告会資料を参照 「デジタルアイデンティティ技術 認可・ID連携・認証 応用」 https://speakerdeck.com/oidfj/20250114-oidf-j-eduwg-techswg
176. Copyright OpenID Foundation Japan - All Rights Reserved. PKCE Downgrade Attack ①攻撃者はクライアントからの認可リクエストを手に入れる ②攻撃者は認可リクエストを書き換え、 code_challengeを削除し 認可サーバーにリクエストを送付 ③認可サーバーは攻撃者に認可コードを発行 ④攻撃者はクライアントのリダイレクト URLに自分の認可コードを 付与し被害者に送付 ⑤被害者がURLにアクセス ⑥クライアントは攻撃者の認可コードを使いトークンリクエスト ⑦認可サーバーはアクセストークン発行 ※このときクライアントはcode_verifierをリクエストに含めているが、認可コー ドはcode_challengeを指定せず発行したものなので、認可サーバーは code_verifierを無視してアクセストークンを発行する ⑧被害者のセッションが攻撃者のリソースに紐びつき、被害者が 自分の個人情報を攻撃者のリソースにアップロードしてしまうと いった被害が生じる 176 CSRF (クロスサイトリクエストフォージェリ)の一種で、認可サーバがPKCEの利用を必須としていない場合、CSRF 対策がPKCEのみの場合、この攻撃に対する脆弱性が生じる可能性がある
177. Copyright OpenID Foundation Japan - All Rights Reserved. PKCE Downgrade Attack 177 対策 ・認可サーバは、 code_challengeが認可リクエスト に含まれているかどうかを確認し、その情報を認可 コードと紐づけて保管しなければならない (MUST) ・認可サーバーはトークンリクエストの処理時に、認 可コード発行時に code_challengeが未指定だった にもかかわらず、 code_verifierが送られてきたリクエ ストは拒否しなければならない (MUST) code：attacker_code code_challenge：無し
178. Copyright OpenID Foundation Japan - All Rights Reserved. Insufficient Redirection URI Validation リダイレクトURL検証に利⽤されるパターンマッチングを逆⼿に取り、認可コー ドやアクセストークンが攻撃者に取得されてしまう 178 前提: クライアントのRedirectURLとして⽂字列では なくワイルドカード等のパターンマッチングを 指定している 攻撃者がパターンマッチングするエンドポイン トを作成して、認可完了時に利⽤させると、攻 撃者のサーバに認可コードやアクセストークン を渡してしまうことになる 対策 RedirectURL検証は⽂字列の完全⼀致⽐較する GrantType: code, ClientType: Confidential Client 登録RedirectUrl: 「https://*.sometime.example/*」
179. Copyright OpenID Foundation Japan - All Rights Reserved. Credential Leakage via Browser History 認可コードやアクセストークンがブラウザの履歴に残ることで攻撃される 179 認可コードについて リダイレクトURLに含まれる認可コードがブラウザの履歴に残るケース 対策 - 認可コードが何回も使⽤できることを防ぐ - post responseモードを使⽤する アクセストークンについて アクセストークンをクエリパラメータに利⽤している場合ブラウザの履歴に残る。 対策 - クライアントはクエリパラメータにアクセストークンを使⽤してはいけない(MUST NOT)
180. Copyright OpenID Foundation Japan - All Rights Reserved. Mix-Up Attacks クライアントが2つ以上の認可サーバーと通信し、そのうち１つ以上が攻撃者の 認可サーバーのときに認可コードやアクセストークンが取得される攻撃 180 前提: - 2つ以上の認可サーバーと連携することがある - 各々リダイレクトURLは共通している - 少なくとも1つ以上の認可サーバが攻撃者が⽤意したものである 認可フローの途中で、連携する認可サーバがすり替わってしまうことがで発 ⽣する。 認可フロー開始時の通信先は攻撃者のものだが、正規の認可サーバーとの連 携に途中で代わり、取得した認可コード‧アクセストークンを開始時点の攻 撃者の認可サーバへ送ってしまう。
181. Copyright OpenID Foundation Japan - All Rights Reserved. Mix-Up Attacksのシーケンス 181 ユーザーに攻撃者認可サーバーと認可フローをス タートさせる。 バックエンドは、選択した認可サーバーをセッショ ン等に保存し、攻撃者認可サーバへのリダイレクト させる。 攻撃者認可サーバーは、正規の認可サーバーにリダ イレクトさせるように書き換える。 正規の認可サーバーのログイン/認可画⾯を経て、リ ダイレクトURLに認可コードが送られる バックエンドは取得した認可コードをトークンエン ドポイントの認可サーバを特定するためにセッショ ンから判定する。 セッションに保存された先は攻撃者の認可サーバの ため、攻撃者に認可コードが送られる。 ClientType: Confidential Client
182. Copyright OpenID Foundation Japan - All Rights Reserved. Mix-Up Attacksのバリエーション 182 Mix-upインタラプション ユーザーが開始した認可フローの通信を攻撃者が改ざんする中間者攻撃により成⽴するもの。ユーザは正規の認可サー バーとフローを開始したはずだが、攻撃者によって通信先を攻撃者の認可サーバーに変更されて発⽣する 暗黙グラント 認可コードではなく、アクセストークンが攻撃者にわたってしまう。 認可サーバーごとのリダイレクトURI 攻撃者は事前に正規の認可サーバにクライアントを登録しておく。ユーザーが攻撃者との認可フローを開始すると、リ ダイレクトURIは攻撃者のまま、clientIdを正規の認可サーバーのものに書き換える。正規の認可サーバ⽤の認可コード が、攻撃者⽤のリダイレクトURIに送られて奪われてしまう。 OpenID Connect OpenID Connect Discovery機能を⽤いて、認可エンドポイントは正規の認可サーバーに、トークエンドポイントは攻 撃者のものに設定することで可能となる。
183. Copyright OpenID Foundation Japan - All Rights Reserved. Mix-Up Attacksの対策 原因は、共通RedirectURlを使⽤することで意図しないサーバに認可コード等を 送ってしまうこと 183 1. 認可サーバ個別のRedirectURLを⽤意する クライアントは認可レスポンスが正しい発⾏者から送られたものかどうかをチェックしなければならない。認可レスポンス を受け取ったURIと発⾏者に対応するリダイレクトURIを⽐較して、正しい発⾏者からのレスポンスであることを検証しなけ ればならず、異なる場合はフローを中断しなければならない。 ただし、Mix-upバリエーションにある攻撃を回避できないので、他に⼿段がない場合のみ採⽤されるべき。 2. issパラメータの利⽤ RedirectURLのクエリパラメーターに認可コードだけではなく、どこが発⾏したものかというメタ情報も追加することで防 ぐ。 たとえば、https://hoge.example.com/callback&code=fuga&iss=piyo.auth.comのように発⾏元の情報を加える。iss情 報をうけとったクライアントは開始時点の認可サーバーのものか検証しなければならず、異なる場合は認可フローを中断し なけらばならない。
184. Copyright OpenID Foundation Japan - All Rights Reserved. Mix-Up Attacks対策シーケンス 184 正規の認可サーバーは、リダイレクトURLと ⼀緒にissパラメータを送信する。 バックエンドはissとセッションに保存された 認可サーバが⼀致していないと、トークン取 得処理に進まず中断させる。 これによって認可コードが攻撃者にわたって しまうことを防ぐことができる。 ClientType: Confidential Client
185. Copyright OpenID Foundation Japan - All Rights Reserved. Authorization Code Injection 185 攻撃者が取得した認可コードをつかってアクセストークンなどの取得しようとす る攻撃 Public Clientの場合 攻撃者は認可コードを認可サーバのトークンエンドポイントに送ってアクセストークンを取得する Confidential Clientの場合 攻撃者⾃⾝のセッションで利⽤される認可コードを盗んだ認可コードと差し替えることでリソースにアク セスする 対策 - PKCEを利⽤することで、Public ClientとConfidential Clientどちらも守ることができる - OIDCではNonce利⽤することで防ぐことができる
186. Copyright OpenID Foundation Japan - All Rights Reserved. Access Token Injection 186 攻撃者が盗んだアクセストークンを正規のクライアントに注⼊し、 不正にリソースへアクセスする攻撃 発⽣条件 ①Implicit Grantを利⽤しているケースで発⽣（2.1.2. Implicit Grant） ※発⽣時シーケンスは次項参照  アクセストークンをパラメータとして返却することで、攻撃者は容易にアクセストークンを搾取することが可能  RFC9700でImplicit Grantは⾮推奨となっている ②Refererヘッダーによる認証情報漏洩（4.2 . Refererヘッダーによる認証情報漏洩）  ※発⽣時シーケンスは「Credential Leakage via Referer Headers」章参照  認可リクエストURIや認可レスポンスURIの内容が、Referer HTTP headerから漏洩し、アクセストークンが開⽰される可能性あり 影響 問題 説明 なりすまし 攻撃者が⾃分のアクセストークンを注⼊し、正規ユーザーとして振る舞える 情報漏洩 他⼈のセッションを乗っ取ってユーザー情報にアクセス可能
187. Copyright OpenID Foundation Japan - All Rights Reserved. Access Token Injection ①Implicit Grantを利用時の発生フロー アクセストークン B 187
188. Copyright OpenID Foundation Japan - All Rights Reserved. 188 Access Token Injection 対策 ①. Implicit Grantを使用すべきではない　 (SHOULD NOT) 　OIDCで新規開発する場合は、認可コードフローを利用する ②-1. アクセストークンの検証　 [クライアント] 　・IDトークン/アクセストークン受領時に実施 　・IDトークン内 at_hash と、取得済アクセストークンのハッシュの整合性を確認する ②-2. トークンのバインディング　 [認可サーバ/リソースサーバ/クライアント] 　・DPoP（Demonstration of Proof-of-Possession）を使用する 　　 アクセストークンを特定のクライアントやデバイスにバインドするこで、盗まれたトークンが他の環境で使用を防ぐ ②-3. トークンのスコープとオーディエンスの制限　 [認可サーバ/リソースサーバ/クライアント] 　・Scope/Audienceの制限する 　　Scopeを最小限に制限することでトークンが悪用されたときの影響を限定する 　　Audienceを指定することで他のリソースサーバで使用されないようにする
189. Copyright OpenID Foundation Japan - All Rights Reserved. Cross Site Request Forgery 189 デジタルアイデンティティ技術 認可‧ID連携‧認証 応⽤にて紹介のため割愛 正規のクライアントを騙して、リダイレクトURLに不正なリクエストを送り、攻 撃者が管理するリソースにアクセスする攻撃
190. Copyright OpenID Foundation Japan - All Rights Reserved. Access Token Leakage at the Resource Server 190 攻撃者のリソースサーバにアクセストークンを送信させる 攻撃者が⽤意したリソースサーバを接続先に設定するように騙してアクセストークンを奪う。 メール、カレンダー、eHealth, オープンバンキングなどの標準化されたAPIを使うときにリソースサーバを ユーザや管理者が⾃由に設定できる場合、攻撃者のものに設定させることで発⽣する リソースサーバが侵害された場合 攻撃者にリソースサーバがのっとられると、ログファイルをみられたり、完全制御されてしまう。 対策 送信者制限アクセストークンをつかって正当なクライアントしか利⽤できないようにすべきである(SHOULD) オーディエンス制限アクセストークンをつかってリソースサーバはトークンを検証すべきである(SHOULD) アクセストークンを平⽂で保存したり転送してはいけない(MUST NOT)
191. Copyright OpenID Foundation Japan - All Rights Reserved. Open Redirection オープンリダイレクトとは、URLパラメータ(クエリストリング)をつかって redirect先を指定し遷移させる仕組み 191 例) https://example.com?redirect=https%3A%2F%2Fattacker.example.com%0D%0A リダイレクト先にURLエンコードされたhttps://attacker.example.comが指定されてる。 クライアントまたは認可サーバのどちらでもオープンリダイレクトを利⽤して悪 意あるサイトに誘導させる恐れがある
192. Copyright OpenID Foundation Japan - All Rights Reserved. クライアント側のOpen Redirector 前提条件: confidential client リダイレクトURL: https://backend.com/redirect?redirect_uri=<悪意サイト> 192 攻撃者が事前に認可クライアントを作成し てリダイレクトURLのオープンリダイレク トに悪意サイト先を指定する。 攻撃者は登録クライアントをつかってユー ザーに認可フローを開始させる。 最終的に悪意サイトにリダイレクトされ、 リファラーから認可コードが盗まれる。
193. Copyright OpenID Foundation Japan - All Rights Reserved. 認可サーバ側のOpen Redirector 前提条件: confidential client リダイレクトURL: https://attacker.example.com 193 ユーザーは怪しいアプリと気付き拒否する が、認可サーバは登録されたリダイレクト URLに遷移させる。 意図的エラーとなる認可リクエストを送信 させて登録リダイレクトURLに遷移させ る。 悪意サイトに遷移してることに気づかない ユーザーは、再度表⽰されるログイン画⾯ を⼊⼒してしまい認証情報を盗まれる。
194. Copyright OpenID Foundation Japan - All Rights Reserved. Open Redirectorの対策 攻撃者によってリダイレクトURIが悪意サイトに設定されること 194 1. クライアント側のOpen Redirector open redirectorを⾃由に設定させてはいけない。(MUST NOT) ホワイトリスト等を⽤意して、許可されたリダイレクト先のみ遷移させるべきである。 2. サーバー側のOpen Redirector 認可サーバはリダイレクトURIが信頼されたものである場合のみリダイレクトすべきである。(SHOULD) 信頼されていないリダイレクト先であれば、ユーザーに知らせてユーザーに判断を任せるても良い。(MAY)
195. Copyright OpenID Foundation Japan - All Rights Reserved. 307 Redirect 307リダイレクトを利⽤すると、リクエスト時のメソッドとボディ(機密情報)をリ ダイレクト先(攻撃者)に送ってしまうこと。 195 307 Redirectはリクエストと同じメソッドとリクエ ストボディをリダイレクト先でも使⽤させる (RFC-9110) 前提条件: ⼀度許可しており同意画⾯のスキップ可 認証画⾯でユーザーが⼊⼒しID/Passwordなどの機 密情報をPOSTリクエストで送ったのち、307 Redirectが使われるとリダイレクト先に機密情報が 含まれたPOSTリクエストが送られる。 対策 Redirectで307を使ってはいけない(MUST NOT) 303を使うべきである(SHOULD)
196. Copyright OpenID Foundation Japan - All Rights Reserved. TLS Terminating Reverse Proxies リバースプロキシがリクエストのカスタムヘッダーをチェックせずアプリケー ションサーバへ通過させると、セキュリティ制御を回避した攻撃ができる 196 攻撃者はX-Forwarded-Forをつかって偽のオリ ジンとしてリクエストを送信する。 リバースプロキシはアプリケーションに送り、 アクセストークンと紐づけられたIPかどうかの チェックが成功してしまう。 対策 リバースプロキシは、アプリケーションサー バーのセキュリティにとって重要なすべての ヘッダー値の正当性を保証するため、受信する リクエストをすべてサニタイズしなければなら ない。(MUST)
197. Copyright OpenID Foundation Japan - All Rights Reserved. Refresh Token Protection 197 リフレッシュトークンとは、新しいトークンを便利かつユーザーフレンドリーに 発⾏する⽅法である。 リフレッシュトークンを使うことで、認可サーバは有効期限が短く、scopeを限 定したアクセストークンが発⾏できるため、アクセストークンの漏洩による潜在 的な影響を軽減し、OAuthのセキュリティ強化にも役⽴つ。 リフレッシュトークン保護ではこのリフレッシュトークンに対するセキュリティ 対策について、RFC6749の範囲を超えた推奨事項について説明する。
198. Copyright OpenID Foundation Japan - All Rights Reserved. リフレッシュトークンに対する攻撃 198 リフレッシュトークンは、特定のクライアントに付与されたアクセス範囲全体を 表し、特定のリソースに制限されていない。 攻撃者がリフレッシュトークンを窃取し、再⽣が可能な場合、アクセストークン を作成することでリソースオーナーに成り代わりリソースサーバーにアクセスが 可能となる。
199. Copyright OpenID Foundation Japan - All Rights Reserved. リフレッシュトークンに対する攻撃への対策 RFC6749の10.4.Refresh Tokensでは、以下の事項がセキュリティ対策として述べられている。 • リフレッシュトークンは転送中及び保管中に機密に保持しなければならない • 発⾏されたリフレッシュトークンは、認可サーバーと発⾏されたリフレッシュトークンを 持つクライアントの間のみで共有されなければならない • 認可サーバーはクライアントと発⾏したリフレッシュトークンを紐付けて維持しなければ ならない • リフレッシュトークンは、 RFC6749の1.6.TLS Versionで説明されているように、RFC2818 で定義されているサーバー認証を⽤いて、TLSを使⽤してのみ送信されなければならない （※RFC2818はセキュアなHTTP通信をTLSで⾏う⽅法を定義している） • 認可サーバーはクライアントIDが認証可能であれば、リフレッシュトークンとクライアン トIDの紐付きを確認しなければならない • クライアント認証ができない場合、認可サーバーは不正なリフレッシュトークンを検出す るために他の⼿段を導⼊するべきである • 認可サーバーは認証されていないサービスによってリフレッシュトークンが⽣成、変更、 有効なリフレッシュトークンを⽣成できるような推測をされないようにしなければならな い 199
200. Copyright OpenID Foundation Japan - All Rights Reserved. リフレッシュトークンに対する攻撃への対策 • 認可サーバーはリスク評価に基づき、クライアントにリフレッシュトークン を発⾏するかどうかを決定しなければならない。(MUST) もし、認可サーバーがリフレッシュトークンを発⾏しないと決定した場合、 クライアントは認可コードグラントタイプなどの他の⽅法を⽤いてアクセス トークンを取得してもよい。この場合、認可サーバーは、ユーザーエクスペ リエンスを最適化するために、クッキーや永続的なグラントを利⽤して権限 を保管することがある。 • リフレッシュトークンが発⾏された場合、それらのリフレッシュトークン は、リソース所有者が同意したスコープおよびリソースサーバーに紐付けら れなければならない。これは、正当なクライアントによる権限のエスカレー ションを防ぎ、リフレッシュトークン漏洩の影響を軽減するためである。 200 RFC9700では、以下が推奨事項として挙げられている
201. Copyright OpenID Foundation Japan - All Rights Reserved. リフレッシュトークンに対する攻撃への対策 認可サーバーは、悪意のある攻撃者によるリフレッシュトークンのリプレイを検出するために、以下の いずれかの⽅法を使⽤しなければならない（公開クライアントの場合） • 送信者制約付きリフレッシュトークン： 認可サーバーは、リフレッシュトークンを特定のクライアントインスタンスに暗号的に紐付ける （[RFC8705]または[RFC9449]を利⽤する） ◦ RFC8750‧‧‧相互TLS（Transport Layer Security）クライアント認証と証明書に紐付いた アクセストークンの使⽤⽅法を定義 ◦ RFC9449‧‧‧トークンの送信元制御とリプレイアタック攻撃の検出について記載 • リフレッシュトークンのローテーション： 認可サーバーは、アクセストークンのリフレッシュ応答ごとに新しいリフレッシュトークンを発⾏ する。 以前のリフレッシュトークンは無効化されるが、その関係に関する情報は認可サーバーによって保 持される。 リフレッシュトークンが漏洩し、その後攻撃者と正当なクライアントの両⽅によって使⽤された場 合、いずれかが無効化されたリフレッシュトークンを提⽰し、認可サーバーに侵害を通知する。認 可サーバーは、どちらの当事者が無効なリフレッシュトークンを提出したかを判断することはでき ないが、アクティブなリフレッシュトークンを取り消す。 この⽅法は、正当なクライアントが新しい認可グラントを取得する必要があるというコストを伴う が、攻撃を⽌めることができる。 201
202. Copyright OpenID Foundation Japan - All Rights Reserved. リフレッシュトークンに対する攻撃への対策 • 認可サーバーは、以下のようなセキュリティイベントが発⽣した場合に、リ フレッシュトークンを⾃動的に取り消してもよい ◦ パスワードの変更 ◦ 認可サーバーでのログアウト • クライアントが⼀定期間⾮アクティブである場合、つまりリフレッシュトー クンが⼀定期間新しいアクセストークンを取得するために使⽤されていない 場合、リフレッシュトークンは期限切れにすべきである（SHOULD）。有効 期限は認可サーバーの裁量により、これはグローバルな値である場合もあれ ば、クライアントポリシーやリフレッシュトークンに関連付けられたグラン ト（およびその機密性）に基づいて決定される場合もある。 202
203. Copyright OpenID Foundation Japan - All Rights Reserved. Client Impersonating Resource Owner リソースオーナーに紐づくアクセストークンかどうか区別できず、なりすましで データを取得される攻撃 203 認可コードグラントで取得したアクセストークンのsubはリソースオーナーを指す。 クライアントコンフィデンシャルグラントで取得したアクセストークンのsubはクライアントアプリのID を指す。 攻撃者は、クライアントコンフィデンシャルグラントをつかってアクセストークンを取得する。 クライアントIDは⾃由に設定できるため、subにユーザーIDと同じ値を攻撃者は設定する。 このアクセストークンを受け取った認可サーバは、ユーザーIDに発⾏したものと判定してユーザー情報を 攻撃者に渡してしまう。
204. Copyright OpenID Foundation Japan - All Rights Reserved. Client Impersonating Resource Ownerの対策 204 subのユーザーIDとクライアントIDが衝突する可 能性ある場合、クライアントIDを⾃由に設定させ るべきではない。(SHOULD NOT) クライアントIDを設定できるならば、他の⼿段で 区別できる⽅法を認可サーバは提供しなければな らない。(MUST) RFC-9068に記載あるJWT形式のアクセストークンの構造を逆⼿にとった攻撃 Header: {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"} Claims: { "iss": "https://authorization-server.example.com/", "sub": "5ba552d67", "aud": "https://rs.example.com/", "exp": 1639528912, "iat": 1618354090, "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4", "client_id": "s6BhdRkqt3", "scope": "openid profile reademail" } RFC-9068に定義されたサンプルデータ構造
205. Copyright OpenID Foundation Japan - All Rights Reserved. Clickjacking WEBサイトに透明なレイヤーを配置することで視覚的にユーザーを騙して、意図 しない操作を実⾏させる攻撃 205 罠サイトに透明なレイヤーで攻撃者が登録したク ライアントを利⽤した認可フローを始める。 ユーザーがすでにログイン済みの場合、許可画⾯ が透明なiframe上に表⽰されて、ユーザーは意図 せずボタンをクリックしてしまう。 クリックすると認可フローが進み、認可コードが 攻撃者のサーバに送られしまう。
206. Copyright OpenID Foundation Japan - All Rights Reserved. Clickjackingの対策 原因は、意図しない罠サイトでiframeをつかって認可フローを開始してしまって ること。 206 RFC-6819ではX-Frame-Optionsやfrume-bustingといった対策が記述されているが、 RFC-9700ではさらに以下について既述されている。 認可サーバはクリックジャッキングへの対策をしなければならない(MUST) 認可サーバは、Content Security Policy (CSP) Level2以上を使⽤するべきである。(SHOULD) クライアントは、登録したリダイレクトURIのオリジンとは異なるオリジンをフレーミングで使⽤してもよい が(MAY)、認可サーバで管理者は特定のクライアントに対して許可されたオリジンを設定したり動的に登録で きるようにするべきである。(SHOULD) CSPをサポートしていない⼀部のユーザーエージェントに対してはRFC-6819対策をすべきである(SHOULD)
207. Copyright OpenID Foundation Japan - All Rights Reserved. Attacks on In-Browser Communication Flows ポップアップを使った認可フローにおいて、認可コードやアクセストークンを攻 撃者が⽤意した親のウィンドウに送ってしまうこと 207 前提: public clientを使⽤している。 ポップアップで認可フローが始まり完了する と、親ウィンドウに認可コードが送られる。 対策 認可サーバは、postMessgeで認可コードを送 るときに送信先を特定のオリジンに限定しな ければならない。(MUST) 送信先にワイルドカードをつかってはいけな い。(MUST NOT) クライアント側は受け取る認可コードが正規 の認可サーバが発⾏したものかを厳密に チェックしなければならない。(MUST)
208. Copyright OpenID Foundation Japan - All Rights Reserved. まとめ 5. OAuth/OpenID Connect セキュリティベストプラクティス 208
209. Copyright OpenID Foundation Japan - All Rights Reserved. 脅威の⼀覧 209 脅威名 概要 攻撃モデル Insufficient Redirection URI Validation リダイレクトURL検証に利用されるパターンマッチングを逆手 に取り、認可コードやアクセストークンが攻撃者に取得されて しまう A1, A3 Credential Leakage via Referer Headers 認可リクエストURIや認可レスポンスURIの内容が、Referer HTTP headerから漏洩する攻撃 A1, A3, A4 Credential Leakage via Browser History 認可コードやアクセストークンがブラウザの履歴に残ることで 攻撃される A3 Mix-Up Attacks 複数の認可サーバーのうち少なくとも１つが攻撃者の認可 サーバーのときに認可コードなどが取得される攻撃 A1, A2 Authorization Code Injection 盗んだ認可コードをつかってアクセストークンなど取得しよう とする攻撃 A1, A3 Access Token Injection 攻撃者が盗んだアクセストークンを正規のクライアントに注入 し、不正にリソースへアクセスする攻撃 A1
210. Copyright OpenID Foundation Japan - All Rights Reserved. 脅威の⼀覧 210 脅威名 概要 攻撃モデル Cross-Site Request Forgery リダイレクトURLに不正なリクエストを送り、攻撃者が管理する リソースにアクセスする攻撃 A1 PKCE Downgrade Attack 認可サーバがPKCEの利用を必須としていない場合、認可コー ドが盗まれてしまう攻撃 A1, A2 Access Token Leakage at the Resource Server 偽リソースサーバにアクセストークンを送信させたり、認可サー バに侵害されてアクセストークンが盗まれる攻撃 A5 Misuse of Stolen Access Tokens アクセストークンが盗まれ、攻撃者により不正な利用がされて しまう A5 Open Redirection クライアントまたは認可サーバのどちらでもオープンリダイレク トを利用して悪意あるサイトに誘導させる攻撃 A1 307 Redirect リクエスト時のメソッドとボディ (機密情報)をリダイレクト先(攻撃 者)に送ってしまう A1, A3
211. Copyright OpenID Foundation Japan - All Rights Reserved. 脅威の⼀覧 211 脅威名 概要 攻撃モデル TLS Terminating Reverse Proxies リバースプロキシがリクエストをチェックせずアプリケーション サーバへ通過させるとセキュリティを突破できる攻撃 A2 Refresh Token Protection リフレッシュトークンが盗まれて、攻撃者により不正な利用がされ てしまう A5 Client Impersonating Resource Owner アクセストークンのsubの値がクライアントIDかリソースオーナー IDなのかを区別できない場合、なりすませる攻撃 A1 Clickjacking WEBサイトに透明なレイヤーを配置することで視覚的にユー ザーを騙して、意図しない操作を実行させる攻撃 A1 Attacks on In-Browser Communication Flows ポップアップを使った認可フローにおいて、認可コードやアクセス トークンを攻撃者に送ってしまうこと A1
212. Copyright OpenID Foundation Japan - All Rights Reserved.