ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ 2021 / Identity Federation Protocols 2021

Transcript

1. ID連携の標準化仕様紹介と セキュアな実装のための アプローチ ritou 2021/9
   
2. この資料はチーム内勉強会 用に作ったものに色々足し てるうちに別物になってし まったものです。
   
3. ID連携関連の標準化仕様を 知ってもらう、入門編のよ うな立ち位置です。
   
4. まずは何かをできるように するための仕様、セキュリ ティ強化のための仕様があ ることを知っていただけれ ば幸いです
   
5. ID連携機能のための 標準化仕様とユースケース
   
6. いきなり OpenID Connect(OIDC)
   
7. ••でログイン
    Ϣʔβʔ 3FMZJOH
   1BSUZ 0QFO*%
   1SPWJEFS
    Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 
   01ʹϦμΠϨΫτͯ͠
   ೝূΠϕϯτͷ৘ใΛཁٻ 
   ೝূΠϕϯτͷ৘ใΛఏڙ ̏ 
   ϩάΠϯͯ͠ɺ
   31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 7 
   ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4
8. ••でログイン
    Ϣʔβʔ 3FMZJOH
   1BSUZ 0QFO*%
   1SPWJEFS
    Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 
   01ʹϦμΠϨΫτͯ͠
   ೝূΠϕϯτͷ৘ใΛཁٻ 
   ೝূΠϕϯτͷ৘ใΛఏڙ ̏ 
   ϩάΠϯͯ͠ɺ
   31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 8 
   ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4
9. ••でログイン
    Ϣʔβʔ 3FMZJOH
   1BSUZ 0QFO*%
   1SPWJEFS
    Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 
   01ʹϦμΠϨΫτͯ͠
   ೝূΠϕϯτͷ৘ใΛཁٻ 
   ೝূΠϕϯτͷ৘ใΛఏڙ ̏ 
   ϩάΠϯͯ͠ɺ
   31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 9 
   ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4
10. ••でログイン
     Ϣʔβʔ 3FMZJOH
    1BSUZ 0QFO*%
    1SPWJEFS
     Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 
    01ʹϦμΠϨΫτͯ͠
    ೝূΠϕϯτͷ৘ใΛཁٻ 
    ೝূΠϕϯτͷ৘ใΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 10 
    ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4
11. ••でログイン
     Ϣʔβʔ 3FMZJOH
    1BSUZ 0QFO*%
    1SPWJEFS
     Ϣʔβʔ͸31ʹϩάΠϯ ͍ͨ͠ 
    01ʹϦμΠϨΫτͯ͠
    ೝূΠϕϯτͷ৘ใΛཁٻ 
    ೝূΠϕϯτͷ৘ใΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    31ʹଐੑ৘ใΛఏڙ͢Δ͜ͱʹಉҙ 11 
    ೝূΠϕϯτͷ৘ใΛ༻͍ͯ ϩάΠϯঢ়ଶʹ͢Δ 1 6 2 5 3 4
12. OPがユーザーの同意の元、 RPにイベント情報と属性情報を 提供する仕組み
    
13. OpenID Connect (Core) ID連携のためのプロトコル 認証”イベント”の情報を受け渡し ユーザーの属性情報提供
    
14. 次は OAuth 2.0
    
15. 別サービスとの連携
     3FTPVSDF
    0XOFS $MJFOU "VUIPSJ[BUJPO
    4FSWFS
    3FTPVSDF
    4FSWFS
     Ϣʔβʔ͸$MJFOUͰผαʔϏε ͷϦιʔεΛར༻͍ͨ͠ 
    "VUI;
    4FSWFSʹϦμ ΠϨΫτͯ͠
    ϦιʔεΞΫηεΛཁٻ 
    ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 15 
    3FTPVSDF
    4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4
16. 別サービスとの連携
     3FTPVSDF
    0XOFS $MJFOU "VUIPSJ[BUJPO
    4FSWFS
    3FTPVSDF
    4FSWFS
     Ϣʔβʔ͸$MJFOUͰผαʔϏε ͷϦιʔεΛར༻͍ͨ͠ 
    "VUI;
    4FSWFSʹϦμ ΠϨΫτͯ͠
    ϦιʔεΞΫηεΛཁٻ 
    ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 16 
    3FTPVSDF
    4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4
17. 別サービスとの連携
     3FTPVSDF
    0XOFS $MJFOU "VUIPSJ[BUJPO
    4FSWFS
    3FTPVSDF
    4FSWFS
     Ϣʔβʔ͸$MJFOUͰผαʔϏε ͷϦιʔεΛར༻͍ͨ͠ 
    "VUI;
    4FSWFSʹϦμ ΠϨΫτͯ͠
    ϦιʔεΞΫηεΛཁٻ 
    ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 17 
    3FTPVSDF
    4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4
18. 別サービスとの連携
     3FTPVSDF
    0XOFS $MJFOU "VUIPSJ[BUJPO
    4FSWFS
    3FTPVSDF
    4FSWFS
     Ϣʔβʔ͸$MJFOUͰผαʔϏε ͷϦιʔεΛར༻͍ͨ͠ 
    "VUI;
    4FSWFSʹϦμ ΠϨΫτͯ͠
    ϦιʔεΞΫηεΛཁٻ 
    ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 18 
    3FTPVSDF
    4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4
19. 別サービスとの連携
     3FTPVSDF
    0XOFS $MJFOU "VUIPSJ[BUJPO
    4FSWFS
    3FTPVSDF
    4FSWFS
     Ϣʔβʔ͸$MJFOUͰผαʔϏε ͷϦιʔεΛར༻͍ͨ͠ 
    "VUI;
    4FSWFSʹϦμ ΠϨΫτͯ͠
    ϦιʔεΞΫηεΛཁٻ 
    ϦιʔεΞΫηεͷݖݶΛఏڙ ̏ 
    ϩάΠϯͯ͠ɺ
    $MJFOUʹϦιʔεΞΫηεΛఏڙ͢ Δ͜ͱʹಉҙ 19 
    3FTPVSDF
    4FSWFS͔Βऔಘ ͨ͠஋Λར༻͢ΔαʔϏεΛఏڙ 1 6 2 5 3 4
20. 認可サーバーがリソースオーナーの 同意の元で、クライアントに リソースアクセスを提供する仕組み
    
21. 混乱を生むところ 登場人物 (目的が違うので名前は違う) ユーザー vs リソースオーナー Relying Party vs Client OpenID Provider vs AuthZ Server 提供するもの イベント情報、属性情報 vs リソースアクセス
    
22. OIDC vs “OAuth認証" OIDCのRP OPから受け取った情報に紐づくユーザーをログイン状 態にできる OAuthのClient 認可サーバーから受け取ったトークンでリソースサー バー(API)にアクセスする プロフィールAPIにアクセスして受け取った情報に紐づ くユーザーをログイン状態に”できる場合がある”
    
23. OIDC = OAuth 2.0 + Identity Layer ID連携に必要な認証イベント情報のやり取り セキュリティイベント : 5W1H + α 属性情報 : 汎用的なプロフィール情報 OAuth 2.0のトークンのやり取りを拡張 属性情報API : 最新の情報を提供 OAuth 2.0のリソースアクセスで実現
    
24. OIDCで扱う属性情報 sub: ユーザーやデバイス等の識別子 profile: ニックネーム、氏名、プロフィール、 性別、生年月日、アイコン画像、URLなど email: メアド、確認済みフラグ phone number: 電話番号、確認済みフラグ address: 住所
    
25. 属性情報の表現例
    
26. OIDCやOAuth 2.0には 関連仕様がいっぱいあるので いくつか紹介
    
27. OIDC Discovery, OIDC Dynamic Registration
    
28. ログインに利用するOPって 個別に設定が必要だよね…?
    
29. Discovery & Dynamic Registration
     OpenID Connect Discovery エンドユーザーの情報からOPを特定する方法 OPのエンドポイントや仕様のサポート状況を RPが取得するためメタデータ定義 OpenID Connect Dynamic Registration 動的なRP登録
30. Discoveryの実行例
    
31. Dynamic Registration リクエスト/レスポンス例
    
32. ユースケース: RP設定の効率化
     1. 連携対象として“Google”を選択 2. RPはDiscoveryを行い、Googleのエンドポ イントなどを取得 3. (Dynamic Registration非対応の場合な ど)必要な情報を手動で設定
33. ユースケース: “普段利用しているOP”でログイン
     1. ユーザーがメールアドレスを送信 2. RPはOP情報を取得、Dynamic Registrationがサポートされていたら自身 を登録、内部でも情報を保存 3. 取得した情報(ClientIDなど)を用いてID連 携開始
34. Session Management
    
35. OIDCで連携してもOP/RPの セッション状態は同期されない
     “ID連携時” OP/RP共にログイン状態 “OPでログアウト” RPはログイン状態 (逆もあり得る) “RPでログアウト” OPはログイン状態 (他にもRPがいたりする)
36. Session Management関連仕様
     Session Management セッションの同期状態を確認 RP-initiated Logout RP -> OPにログアウトを要求 Front-Channel Logout OP -> RPにフロントチャンネルでログアウトを通知 Back-Channel Logout OP -> RPにバックチャンネルでログアウトを通知
37. ユースケース: ログイン状態の同期
     複数ドメインで構成されるサービスで、ID連携 時のログイン状態が継続しているかを検証可能 シングルログアウト 1 OP : n RPにも対応可能 (実装によっては3rdPartyCookieなどの動向 に注意が必要)
38. Identity Assurance
    
39. 検証済みデータの扱い
     同意の元で サービスに渡せる？ 身元確認！ ユーザー
40. Identity Assurance
     OIDCでOPがユーザーの検証済み属性情報を RPに提供するための仕様 要求 : どんな情報をどういう目的で欲しい 表現 : 検証プロセスの情報 + 属性情報 応答 : IDトークンもしくは属性情報API 犯収法、携帯電話不正利用防止法の定義も
41. 検証済み属性情報の例
     "verified_claims": { "verification": { “trust_ framework": “jp_ aml” }, "claims": { “given_ name#ja-Hani-JP": “太郎", “family_ name#ja-Hani-JP": "東京", “given_ name#ja-Kana-JP": "タロウ", “family_ name#ja-Kana-JP": "トウキョウ", "birthdate": "1981-01-01" } }
42. ユースケース: 本人確認情報の流通
     OPが決済機能で”本人確認” 本人確認書類の画像やマイナンバーカード (JPKI) RPが確認済みの情報やフラグを利用 同様の確認を行うコスト,ユーザーの負担軽 減(どこまで許されるかは仕様の対象外)
43. RISC & CAEP
    
44. ID連携後に非同期になるの はセッションだけではない
     ID連携 してから… 接続環境が変わった
 (リスク評価できる？) アカウント無効化
 (RPは気付ける？)
45. OIDF Shared Signals and Event WG セキュリティイベント、状態変化等のイベン トを共有できるようにする Continuous Access Evaluation Protocol (CAEP) Mitigating Catastrophic Account Compromise (RISC)
    
46. RISC実装例: ID連携解除, 退会の 通知
     OP側で状態変更を検知したらRPのエンドポイ ントにWebhookで送信 セッション無効化 アカウント無効化 退会 サービス側は署名検証してから処理
47. CIBA(シーバ)
    
48. Decoupled Authentication 手元のスマホで認証+α 決済では 3D Secure 2.2 にて登場 OIDCの文脈で実現するのがCIBA
    
49. CIBAでできること 分離された環境によるユースケース Consumption Device: 認証を要求する端末 Authentication Device: 認証を行う端末 端末のローカル認証の利用 FIDOとの組み合わせ
    
50. コンビニ決済 ×CIBA
     コンビニで支払い （ポイントカードを出す） 手元の端末で
 認証とアクセス許可
 （店員に見せなくて良い） 決済完了
51. オフラインのユースケース POS端末 コールセンター 銀行の窓口業務 サブスクライブ決済など
    
52. ここまでのまとめ ID連携のための仕様のうち、こんなことができ るよってのを紹介 単純な〜〜でログイン以外にも結構ある 標準化された仕様がある＝ユースケースに対す るリスクと対策が整理されている ID連携の機能を提供する際はなるべく採用し ていくべき
    
53. ID連携仕様から学ぶ Webアプリケーション間の データ送受信をセキュアに する方法
    
54. セキュリティ強化のための 仕様 基本仕様 : フレームワーク、最もシンプルな実装 拡張仕様 既存仕様と組み合わせたり一部を置き換えるこ とで安全性を高める プロファイル、BCP(Best Current Practice) 気をつけること！仕様の組み合わせ方！
    
55. OAuth 2.0の場合
    
56. 基本仕様と拡張仕様 基本仕様 RFC6749 アクセストークン取得までを定義したフ レームワーク RFC6750 Bearerトークンを用いたシンプルなAPI保護 拡張仕様 RFC7636 PKCEと呼ばれる、モバイルアプリ実装の攻 撃を防ぐための拡張
    
57. 基本仕様と拡張仕様 BCP RFC8252 ネイティブアプリのBCP (策定中) SPAのBCP OAuth 2.1 たくさんのBCPと拡張仕様を整 理して1つのドキュメントとして整理してい るもの
    
58. FAPI
    
59. OIDC FAPI 金融サービス相当のセキュリティレベルが求 められる状況でID連携を提供するためのプロ ファイル Baseline : 中程度の… Advanced : 高度な…
    
60. ここからはFAPIで定義/引用されている 仕様からセキュアなWebアプリケーション 実装のヒントを紹介します
    
61. OIDCで使われている通信 直接通信 : Webアプリ間、Webアプリとモバイ ルアプリ間の通信 クライアント認証つきのリクエスト アクセストークンにより保護されたリクエスト 間接通信 : ブラウザを利用してリダイレクト GET / POST
    
62. クライアント認証 共有鍵暗号方式 クライアントシークレット(テキスト/バイ ナリ)を共有 公開鍵暗号方式 秘密鍵/公開鍵のペアを生成、公開鍵を相 手に渡しておく
    
63. クライアントシークレットを 利用したクライアント認証
     1. そのまま送る 1. POSTパラメータ client_ secret_ post 2. Basic認証の形式 client_ secret_ basic 2. 直接送らず、署名生成の鍵として利用 client_ secret_ jwt 1. 署名付きのJWTを生成して指定することで、ク ライアントシークレットが通信路を流れない
64. 鍵ペアを利用したクライア ント認証
     private_ key__ jwt 秘密鍵を用いて署名付きJWTを生成 受け取った側が公開鍵を用いて署名検証 Mutual TLS TLSのクライアント証明書の仕組みを利用
65. リソースアクセス Bearer Token アクセストークンそのまま利用 Sender-Constrained Token Mutual TLS : TLSのクライアント証明書の仕組 みを利用 署名付きJWT : アクセストークン発行時に鍵ペ アを紐付ける(DPoP)
    
66. 直接通信のポイント 暗号化(Encryption)までは求められない シークレットをそのまま送らない方法が推奨 されている トークンを利用する場合も、JWTなどを用 いてSender-Constrainedにすることでセ キュアにできる
    
67. 間接通信の保護 GETリクエスト クエリパラメータ フラグメントの利用: サーバーログにパラ メータが含まれない データをJWT形式にする: 改ざん検知可能
    
68. 間接通信の保護 POST POSTリクエスト フォームデータ データをJWT形式にする: 改ざん検知可能 (3rd Party CookieやSameSite属性の影響 に注意)
    
69. 間接通信の保護 直接通信との組み合わせ Push(データを送りたい側がリクエスト) 予めデータをPushしておき、取得したキーをGET/ POSTリクエストに含む Pull(データを受け取る側がリクエスト) GET/POSTリクエストに含んだキーに対して受信側にア クセスしてもらう 直接通信を利用することで、複雑な構造のリクエストを 表現可能
    
70. 連続した間接通信の保護 「ブラウザで行って戻ってくる」処理 例：RP->OP->RPというリダイレクト OIDCの認証フローで一般的 CSRFなどなかなか物騒な世界
    
71. 連続した間接通信の保護 セッションに紐づけた値をクエリで引き回す (state @ OAuth 2.0) セッションに紐づけた値を署名つきJWTで 引き回す (OIDC nonce & JAR)
    
72. 間接通信のポイント こちらも暗号化(Encryption)までは求めら れない 署名付きリクエストにすることで改ざん検知 が可能 データをUser-Agent上に流したくない、大 きいサイズのデータをやり取りするような場 合は直接通信と組み合わせる
    
73. ここまでのまとめ OIDCのセキュリティプロファイルや拡張仕 様などで言及されている、直接通信/間接通 信におけるセキュリティ強化のための方法を 紹介した 基本的な部分を押さえておけば仕様を読むこ とがあっても怖くはない…はず
    
74. 仕様の話があまり出てこな かったが…? OIDCの拡張仕様はたくさんあるが、今回紹 介したポイントを細かく組み合わせて作られ ているものが多い (次回があれば)OIDCのシーケンスに対して “ここを強化するためにはこうする” みた いな解説をしたい
    
75. 全体のまとめ ユースケースがある仕様の概要と、セキュリ ティ強化のための考え方を紹介した ID連携では単にユーザーIDを取得するだけで はなく様々な処理の標準化が進められている OIDCの拡張仕様はたくさんあるが、今回紹 介したポイントを細かく組み合わせて作られ ているものが多い
    
76. 終わり