Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

認証の課題とID連携の実装 〜ハンズオン〜

209 views

Published on

タイトル:
『認証の課題とID連携の実装 〜ハンズオン〜』

概要:
FIDO、ID連携(OAuth・OpenID Connect)をはじめとした最近の技術をご紹介します。FIDOは端末とサーバー間でユーザー認証を安全に連携するための仕組みです。OpenID Connectはユーザーの認証と認可を連携するためのID連携の仕組みで、OAuth 2.0を拡張した仕様であり、HTTP通信やJSONなど基礎的なWeb技術によって構成されています。FIDOとID連携の技術を学んだ後、実習ではGolangを用いてWebアプリケーション上にOpenID Connectを実装します。実装の注意点とそのリスク、仕様に施されているセキュリティー対策についてハンズオンを行いながら解説します。

セキュリティ・キャンプ全国大会2019 専門講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 Aug 15, 2019
URL:https://www.ipa.go.jp/jinzai/camp/2019/zenkoku2019_program_list.html#list_d3-b4

Published in: Internet
  • Be the first to comment

認証の課題とID連携の実装 〜ハンズオン〜

  1. 1. セキュリティ・キャンプ全国⼤会2019 専⾨講義 選択コース B4 認証の課題とID連携の実装 〜ハンズオン〜 2019年8⽉15⽇ OpenID ファウンデーション・ジャパン 倉林 雅
  2. 2. プロフィール 倉林 雅(くらはやし まさる) OpenID ファウンデーション・ジャパン 理事 / エバンジェリスト ヤフー株式会社 認証技術⿊帯 / ID・セキュリティエンジニア https://twitter.com/kura_lab 2
  3. 3. 3
  4. 4. アジェンダ 1. はじめに • FIDOとOpenID Connectの概要 2. 認証と認可を理解しよう 3. FIDOを理解しよう 1. FIDO UAF 2. FIDO U2F 3. FIDO2(CTAP/WebAuthn) 4. FIDO2登録フロー 5. FIDO2認証フロー 4. OpenID Connectを理解しよう 1. Implicit Flowの解説 2. トークン置き換え攻撃対策 3. ユーザー識別⼦による脆弱な認証 4. Authorization Code Flowの解説 5. CSRF対策 6. ID Tokenの解説 7. リプレイ攻撃対策 8. UserInfoエンドポイントの解説 9. ユーザー識別⼦ 10. Hybrid Flowの解説 11. OpenID Certificationの紹介 5. まとめ 4
  5. 5. はじめに FIDOとOpenID Connectの概要
  6. 6. FIDOが提供する機能 6 簡単にいうと 「セキュリティとUXを両⽴したユーザー認証」
  7. 7. 7 ログインが求められる
  8. 8. 8 パスワードや確認コードを⼊⼒せずに ⽣体認証などでログイン
  9. 9. OpenID Connectが提供する機能 9 簡単にいうと 「ユーザー認証」と「属性情報取得」
  10. 10. 10 所持しているIDのサービスを選択
  11. 11. 11 ログインをする
  12. 12. 12 同意をする
  13. 13. 13 情報がプリセットされる
  14. 14. 本⽇のゴール 14 認証・認可の仕組みを理解する ID連携の実装を通じて セキュリティリスクと対策を学ぶ
  15. 15. 認証と認可を理解しよう
  16. 16. 「認証」と「認可」 16 「認証」を意味する英単語は2つ存在する
  17. 17. 2種類の「認証」 17 ⽤語 説明 Authentication 認証する側とされる側が事前に 共有している情報を確認すること 例)IDとパスワードでユーザーを認証する Certification 信頼できる機関(認証局)が証明書をもとに 「持ち主」の正当性を確認すること 例)クレジットカード会社が発⾏したカードを 店舗に提⽰して所有者を認証する
  18. 18. 2種類の「認証」 18 ⽤語 説明 Authentication 認証する側とされる側が事前に 共有している情報を確認すること 例)IDとパスワードでユーザーを認証する Certification 信頼できる機関(認証局)が証明書をもとに 「持ち主」の正当性を確認すること 例)クレジットカード会社が発⾏したカードを 店舗に提⽰して所有者を認証する OpenID Connectのフローにでてくる認証は 「Authentication」
  19. 19. 「認証」と「認可」 19 「認証」と「認可」の違い
  20. 20. 2種類の「認証」 20 ⽤語 説明 認証 (Authentication/AuthN) アクセスしている相⼿の正当性をチェックして 正規の利⽤者であるかを確認する 認可 (Authorization/AuthZ) 認証済みの利⽤者にサービスの利⽤や リソースへのアクセスなどの権限を与えること
  21. 21. ID連携・認証・プロビジョニング 21 Attributes Single Sign-On Federation Authentication Provisioning OpenID Connect SAML FIDO SCIM
  22. 22. ID連携・認証・プロビジョニング 22 Attributes Single Sign-On Federation Authentication Provisioning OpenID Connect SAML FIDO SCIMユーザーの認証とその結果を 連携するID連携は仕様が分かれており 補完関係にある
  23. 23. FIDOを理解しよう
  24. 24. ⽤語集 • クレデンシャル情報 • パスワードや⽣体情報などユーザー認証に必要な情報 • RP (Relying Party) • ユーザーのIDを登録、認証し管理するサーバー(FIDO2 Server) • Authenticator(認証器) • 秘密鍵・公開鍵のペアを⽣成し、RPへ送信する署名を⽣成する • Client-Side • Authenticatorやユーザー端末などの総称 • WebAuthn Client • ブラウザーなどのUser Agent 24
  25. 25. ⽤語集 • クレデンシャル情報 • パスワードや⽣体情報などユーザー認証に必要な情報 • RP (Relying Party) • ユーザーのIDを登録、認証し管理するサーバー(FIDO2 Server) • Authenticator(認証器) • 秘密鍵・公開鍵のペアを⽣成し、RPへ送信する署名を⽣成する • Client-Side • Authenticatorやユーザー端末などの総称 • WebAuthn Client • ブラウザーなどのUser Agent 25 FIDOではIDを管理・認証するサーバーがRP OpenID ConnectではRPが逆の⽴場になるので 認証結果を受け取る役割がRPと覚えとくとよい
  26. 26. FIDOとは • FIDO = Fast IDentity Online(⾼速なオンラインID認証) • 顔や指紋のクレデンシャル情報をサーバーへ送らず保存しない • ⽣体認証などのさまざまな認証⽅法に対応 26
  27. 27. FIDOで提供している仕様 27 UAF U2F FIDO2 CTAP WebAuthn FIDO Allianceでは パスワードレス型、パスワード補完型、 FIDO認証を拡⼤するための拡張仕様を提供している
  28. 28. FIDO UAF •UAF = Universal Authentication Framework •主にスマートフォン(アプリ)を想定した パスワードレス型の認証 •所持認証 + ⽣体認証など 28 UAF
  29. 29. FIDO U2F •U2F = Universal 2nd Factor •主にPCのWebブラウザーで⼆要素認証を 想定したパスワード補完型の認証 •記憶認証 + 所持認証 29 U2F
  30. 30. FIDO2 • FIDO2の仕様は、FIDO AllianceのClient-to- Authenticator Protocol(CTAP)とW3CのWebAuthn から構成される • スマートフォンとPCを想定し、⼀般的なデバイス (USB、BLE、NFCなどが利⽤ できる端末)を活⽤した認証 30 FIDO2 CTAP WebAuthn
  31. 31. • IDとクレデンシャル情報(パスワードなど)を認証サーバーへ送信 • 認証サーバーはIDとクレデンシャル情報を検証し認証 • パスワードなどを⼊⼒する場合、通信経路での漏洩やフィッシングでの 窃取の懸念あり • クレデンシャル情報を認証サーバーで保存するため漏洩のリスクは⼤きい 従来の認証モデル 31 ユーザー 認証サーバー クレデンシャル情報 (パスワード) クレデンシャル 情報の検証 クレデンシャル 情報の⼊⼒ クレデンシャル情報 (パスワード)
  32. 32. • デバイスの認証器(Authenticator)が本⼈性を検証 • 検証結果に秘密鍵で署名し認証サーバーに送信 • 認証サーバーで公開鍵を使って署名を検証しユーザーを認証 • クレデンシャル情報が流れないため、パスワードのフィッシング耐性あり FIDO認証モデル 32 ユーザー 認証サーバー検証結果(署名) 秘密鍵 公開鍵 クレデンシャル 情報の⼊⼒ 検証結果の 妥当性を確認
  33. 33. CTAPとWebAuthn • CTAPはAuthenticator(認証器)とWebAuthn Clientの通信を定義する プロトコル • WebAuthnはRelying Party(FIDO2認証サーバー)からWebAuthn Client経由でクレデンシャルを操作するプロトコル 33 CTAP2 WebAuthn Authenticator WebAuthn Client(ブラウザーなど) Relying Party USB/BLE/NFC...
  34. 34. FIDOを理解しよう FIDO2登録フロー
  35. 35. FIDO2登録フロー 35 End-User Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) Client-Side FIDOはサーバーがRP
  36. 36. FIDO2登録フロー 36 End-User Relying Party (FIDO2 Server) 0-2.ログインID 既存のログインIDに対して FIDOの登録開始 ※ログインIDがない場合もある Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.登録開始
  37. 37. FIDO2登録フロー 37 End-User Relying Party (FIDO2 Server) 0-2.ログインID 1.navigator.credential.create() 2.認証要求 JavaScript API経由でユーザー認証と Authenticatorへ鍵ペアの⽣成を要求 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.登録開始
  38. 38. FIDO2登録フロー 38 End-User Relying Party (FIDO2 Server) 0-2.ログインID 1.navigator.credential.create() 3.認証要求 2.認証要求 4.認証 5.秘密鍵/公開鍵⽣成 秘密鍵格納 Authenticatorが指紋や顔などの 認証を要求し、認証を終えると鍵ペアを ⽣成し秘密鍵をAuthenticator内に保存 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.登録開始
  39. 39. FIDO2登録フロー 39 End-User Relying Party (FIDO2 Server) 0-2.ログインID 1.navigator.credential.create() 3.認証要求 7.公開鍵 2.認証要求 4.認証 6.公開鍵5.秘密鍵/公開鍵⽣成 秘密鍵格納 8.ログインIDに 公開鍵を保存 公開鍵のみをRPへ送信し ログインIDへ紐付けて保存 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.登録開始
  40. 40. FIDO2登録フロー 40 End-User Relying Party (FIDO2 Server) 0-2.ログインID 1.navigator.credential.create() 3.認証要求 7.公開鍵 2.認証要求 9.登録完了 10.登録完了 4.認証 6.公開鍵5.秘密鍵/公開鍵⽣成 秘密鍵格納 8.ログインIDに 公開鍵を保存 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.登録開始
  41. 41. FIDOを理解しよう FIDO2認証フロー
  42. 42. FIDO2認証フロー 42 End-User Relying Party (FIDO2 Server) FIDOはサーバーがRP Authenticator Web Browser (WebAuthn Client) Client-Side
  43. 43. FIDO2認証フロー 43 End-User Relying Party (FIDO2 Server) 0-2.ログインID 登録しているログインIDを 指定して認証開始 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始
  44. 44. FIDO2認証フロー 44 End-User Relying Party (FIDO2 Server) 0-2.ログインID 3.認証要求 2.navigator.credential.get() 1.challenge⽣成 challengeを⽣成しWebAuthn Clientへ送信 JavaScript API経由で Authenticatorに保存してある秘密鍵を取得 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始
  45. 45. 6.秘密鍵を検索 challengeを秘密鍵で署名 FIDO2認証フロー 45 End-User Relying Party (FIDO2 Server) 0-2.ログインID 4.認証要求 3.認証要求 5.認証 2.navigator.credential.get() 1.challenge⽣成 Authenticatorが認証を要求し 認証が完了すると 秘密鍵でchallengeに署名 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始
  46. 46. 6.秘密鍵を検索 challengeを秘密鍵で署名 FIDO2認証フロー 46 End-User Relying Party (FIDO2 Server) 0-2.ログインID 4.認証要求 8.署名されたchallenge 3.認証要求 5.認証 7.署名されたchallenge 9.署名を 公開鍵で検証 2.navigator.credential.get() 1.challenge⽣成 署名されたchallengeを RPに保存している公開鍵で検証 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始
  47. 47. 6.秘密鍵を検索 challengeを秘密鍵で署名 FIDO2認証フロー 47 End-User Relying Party (FIDO2 Server) 0-2.ログインID 4.認証要求 8.署名されたchallenge 3.認証要求 10.認証完了 11.認証完了 5.認証 7.署名されたchallenge 9.署名を 公開鍵で検証 2.navigator.credential.get() 1.challenge⽣成 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始
  48. 48. OpenID Connectを理解しよう
  49. 49. ⽤語集 • IdP (Identity Provider) • 認証を⾏ってID、属性情報を提供する • RP (Relying Party) • IdPの認証を利⽤してEnd-Userにサービスを提供する • Claim • IdPやEnd-Userなどの属性情報 49
  50. 50. ⽤語集 • IdP (Identity Provider) • 認証を⾏ってID、属性情報を提供する • RP (Relying Party) • IdPの認証を利⽤してEnd-Userにサービスを提供する • Claim • IdPやEnd-Userなどの属性情報 50 OpenID Connectでは IDを管理・認証する サーバーはRPではない 認証結果を受け取る側が RPと覚えとくとよい
  51. 51. OpenIDとは • OpenIDはユーザーの認証の技術 • (OpenID AXで属性を取得する拡張はある) 51
  52. 52. OpenID • 2006年 • OpenID Authentication 1.1 • OpenID Simple Registration Extension 1.0 • 2007年 • OpenID Authentication 2.0 • OpenID Attribute Exchange 1.0 52
  53. 53. OAuthとは • OAuth 1.0とOAuth 2.0はユーザーの認可の技術 • ユーザーのリソースアクセス(Web API)が⽬的 53
  54. 54. OAuth • 2009年 • OAuth 1.0a • 2010年 • OAuth 1.0 Protocol • 2012年 • OAuth 2.0 Authorization Framework 54 オーオースッ
  55. 55. OpenID Connectとは • ユーザーの認証と認可を兼ね備えた技術 • OpenIDとは異なる技術でOAuth 2.0を拡張した プロトコル • 2014年2⽉にローンチ 55
  56. 56. 56
  57. 57. 57 OpenID ConnectはOAuth 2.0や JSON Web Tokenなどの技術で構成されている
  58. 58. OpenID Connect 58 Web API連携・ユーザー認証・ ユーザー属性情報取得に 必要な仕様が定義れている 認可 認証 属性取得 OAuth 2.0 JSON Web Token
  59. 59. OpenID Connectの技術 OpenID Connectには Webアプリケーションと セキュリティの技術が満載 59
  60. 60. OpenID Connectの技術 1. Locationヘッダー(リダイレクト) 2. CSRF対策 3. HTTP通信 4. Basic認証(トークン発⾏時のクライアント認証) 5. JSON Web Token 6. リプレイ攻撃対策 7. Bearer Token など 60
  61. 61. OpenID Connectの技術 RPを実装することで 基礎から応⽤までのWeb技術を 学ぶことができる 61
  62. 62. OpenID Connectを理解しよう Implicit Flowの解説
  63. 63. Implicit Flow • 主にスクリプト⾔語を⽤いて実装されブラウザ上で 動作するClientによって使⽤される • Access TokenとID Tokenは、Clientに直接返却され End-UserとEnd-UserのUser Agentにアクセスする アプリケーションに露出する可能性がある • Authorization Serverはクライアント認証を⾏わない 63
  64. 64. 64 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo Implicit Flow OpenID Connectは ClientがRP サーバーはIdP
  65. 65. 65 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 Implicit Flow
  66. 66. 66 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト Implicit Flow RPからIdPへ認証・認可を User Agentを利⽤して GETのリダイレクト(もしくはPOST) でリクエスト
  67. 67. 67 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ Implicit Flow パスワードやSMSの確認コード、 FIDOなどでユーザーを認証
  68. 68. 68 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 4.同意画⾯ Implicit Flow RPへの認可の権限に対して ユーザーに同意を取得
  69. 69. 69 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 4.同意画⾯ Implicit Flow 認可のAccess Tokenと IdPが⾏ったユーザー認証の情報を含むID Tokenを User Agentを利⽤してリダイレクトで返却
  70. 70. 70 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 4.同意画⾯ 7.ログイン完了 Implicit Flow ID Tokenを検証しClientで ログイン処理を完了
  71. 71. 71 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 4.同意画⾯ 7.ログイン完了 Implicit Flow 属性情報の取得が必要な場合は UserInfoエンドポイントへ Access Tokenを送信
  72. 72. 72 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow 各属性情報がJSONで返却される
  73. 73. 73 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow
  74. 74. 74 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow OpenID ConnectはID連携の仕様を定義しているが IdPのユーザーに対する ログインや同意取得の処理は定義していない
  75. 75. 75 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow ID 連携 ユーザー 認証 (同意) ID 連携 ユーザーの認証(同意) とID連携は補完関係
  76. 76. 76 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow ログインにパスワードや FIDOなどユーザー認証の ⼿段は各IdPで異なる ID 連携 ユーザー 認証 (同意) ID 連携
  77. 77. OpenID Connectを理解しよう トークン置き換え攻撃対策
  78. 78. OAuth認証のリスク 78 リスク トークン置き換え攻撃 事象 Access Tokenを置き換えることで悪意あるユーザーとして 認証させて「乗っ取らせ」を⾏いユーザー情報を 登録させるなどのセキュリティホールを⽣む可能性あり 対策 Access Tokenの置き換えの⼝をつくらない 受け取ったTokenの発⾏対象のクライアントを検証する
  79. 79. OAuth認証のリスク 79 リスク トークン置き換え攻撃 事象 Access Tokenを置き換えることで悪意あるユーザーとして 認証させて「乗っ取らせ」を⾏いユーザー情報を登録させ るなどのセキュリティホールを⽣む可能性あり 対策 Access Tokenの置き換えの⼝をつくらない 受け取ったTokenの発⾏対象のクライアントを検証する OAuthは「認可」の仕組みであり 「認証」のためのセキュリティ対策が 仕様に組み込まれていない
  80. 80. トークン置き換え攻撃 • クライアントで取得したAccess Tokenをサーバーへ送信し ユーザー識別⼦を取得して認証する • クライアントとサーバー間でのAccess Tokenの受け渡しは 仕様に定義されていない • サーバーへ送信するAccess Tokenを別のものに置き換える ことで別のユーザーでログインできてしまう脆弱性となりうる 80
  81. 81. 81 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token 8.Access Token 10.Claims(ユーザー識別⼦) 4.同意画⾯ 12.ログイン完了 9.Access Token 11.ログイン処理 Implicit Flow ⼀⾒Implicitを正しく 実装していそうですが 脆弱な実装は どこでしょう︖
  82. 82. 82 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token 8.Access Token 10.Claims(ユーザー識別⼦) 4.同意画⾯ 12.ログイン完了 9.Access Token 11.ログイン処理 Implicit Flow 脆弱な実装はココ
  83. 83. 83 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token 8.Access Token 10.Claims(ユーザー識別⼦) 4.同意画⾯ 12.ログイン完了 9.Access Token 11.ログイン処理 Implicit Flow Access Tokenは どのRPへ発⾏したものかRPが判定できない ※OAuth 2.0 Token Introspectionなどを⽤いると 判定できる場合もある 別のRPで取得した 他者のユーザーのAccess Tokenに 置き換えしログインできてしまう
  84. 84. 【演習準備】Golang実⾏環境セットアップ 84 以下の⼿順に従って演習の準備をしましょう https://github.com/kura-lab/seccamp2019/tree/master/practice00
  85. 85. 【演習】トークン置き換え攻撃体験 85 トークン置き換え攻撃を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice01-1
  86. 86. トークン置き換え攻撃 クライアントサイドで取得した Access Tokenをサーバーサイドへ送信する ユーザー認証は実装してはならない 86
  87. 87. OpenID Connectを理解しよう ユーザー識別⼦による脆弱な認証
  88. 88. 88 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims(ユーザー識別⼦) 4.同意画⾯ 12.属性情報取得 ログイン完了 Implicit Flow 10.ユーザー識別⼦ 11.ログイン処理 ⼀⾒Implicitを正しく 実装していそうですが 脆弱な実装は どこでしょう︖
  89. 89. 89 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims(ユーザー識別⼦) 4.同意画⾯ 12.属性情報取得 ログイン完了 Implicit Flow 10.ユーザー識別⼦ 11.ログイン処理 脆弱な実装はココ
  90. 90. 90 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims(ユーザー識別⼦) 4.同意画⾯ 12.属性情報取得 ログイン完了 Implicit Flow 10.他者のユーザー識別⼦ 11.ログイン処理 他者のユーザー識別⼦を送信することで 不正ログインできてしまう脆弱性となる 特に複数のRPで共通のユーザー識別⼦を 返却するIdPの場合は、他のRPで取得した ユーザー識別⼦も利⽤できてしまう
  91. 91. 91 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow Implicit FlowはClient サイドのユーザー認証と 属性取得のためのフロー Back-End Serverで 認証処理を⾏う場合は Authorization Code Flowを利⽤するのがよい
  92. 92. 【演習】ユーザー識別⼦による脆弱な認証体験 92 ユーザー識別⼦による 脆弱な認証を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice01-2
  93. 93. ユーザー識別⼦による脆弱な認証 OpenID Connectは 「認可」のOAuth 2.0に ユーザーの「認証」の機能を追加 93
  94. 94. ユーザー識別⼦による脆弱な認証 安易な独⾃実装は脆弱性につながるため ユースケースと対応する各フローを理解し OpenID Connectを正しく実装しましょう 94
  95. 95. OpenID Connectを理解しよう Authorization Code Flowの解説
  96. 96. Authorization Code Flow • ClientにAuthorization Codeを返却し、Clientはそれを直接ID Token およびAccess Tokenと交換するため、User AgentやUser Agent上の 他の不正アプリケーションなどにトークンが露呈することがない • Authorization Serverは、Authorization CodeをAccess Tokenと 交換する前にClientを認証することもできる • Client SecretをClientとAuthorization Serverの間でセキュアに 保てるClientに適している 96
  97. 97. 97 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo Authorization Code Flow Authorization Code Flowの場合 IdPの認証結果を受け取るのは Back-End Server
  98. 98. 98 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 Authorization Code Flow
  99. 99. 99 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 0-2.処理開始 Authorization Code Flow RPからIdPへ認証・認可を User Agentを利⽤して GETのリダイレクト(もしくはPOST) でリクエスト
  100. 100. 100 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 4.同意画⾯ 0-2.処理開始 Authorization Code Flow IdPがログイン・同意をユーザーに要求
  101. 101. 101 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 4.同意画⾯ 0-2.処理開始 6.Authorization Code Authorization Code Flow ユーザーが認可した情報が Authorization Codeとして User Agentを通じて Back-End Serverへ返却される Access Token等を 直接Clientサイドへ返却せず 有効期限の短い⼀時トークンとして Authorization Codeを 返却するためImplicit Flowよりも強固
  102. 102. 102 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Authorization Code Flow Authorization Codeに加えてサーバー間で Client IDとClient Secretによるクライアント認証を ⾏うためImplicit Flowよりも強固
  103. 103. 103 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) Authorization Code Flow 認可のAccess Tokenと IdPが⾏ったユーザー認証の 情報を含むID Tokenを返却
  104. 104. 104 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 9.ログインセッション 発⾏ 10.ログイン完了 Authorization Code Flow ID Tokenを検証しClientで ログイン処理を完了
  105. 105. 105 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 11.Access Token 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 9.ログインセッション 発⾏ 10.ログイン完了 Authorization Code Flow 属性情報の取得が必要な場合は UserInfoエンドポイントへ Access Tokenを送信
  106. 106. 106 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 11.Access Token 12.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 13.属性情報取得完了 9.ログインセッション 発⾏ 10.ログイン完了 Authorization Code Flow 各属性情報がJSONで返却される
  107. 107. 107 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 11.Access Token 12.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 13.属性情報取得完了 9.ログインセッション 発⾏ 10.ログイン完了 Authorization Code Flow
  108. 108. OpenID Connectを理解しよう CSRF対策
  109. 109. CSRF (Cross-Site Request Forgery) ⼀般的な場合 • 別のサイトに⽤意したコンテンツ上の罠のリンクを踏ませるこ となどをきっかけとして、インターネットショッピングの最終 決済や退会などのWebアプリケーションの重要な処理を呼び出 すようユーザーを誘導する攻撃 OAuth 2.0/OpenID Connectの場合 • 悪意あるユーザーの認可コードを被害者に乗っ取らせ情報を窃 取する 112
  110. 110. 113 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 9.Access Token 10.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 11.属性情報取得 ログイン完了 Authorization Code Flow CSRFの 攻撃対象になる部分は どこでしょう︖
  111. 111. 114 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 9.Access Token 10.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 11.属性情報取得 ログイン完了 対策なしのままではAuthorizationリクエストから Authorization Codeを受け取るまで セッションが同⼀であることを保証できない 他ユーザーのAuthorization Codeに 置き換えができてしまう Authorization Code Flow
  112. 112. 115 Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 9.Access Token 10.Claims 4.同意画⾯ 0-2.処理開始 6.悪意あるユーザーのAuthorization Code 7.Tokenリクエスト(Authorization Code) 11.属性情報取得 ログイン完了 悪意あるユーザーが⾃⾝のIDで ログイン、同意を⾏いBE Serverへ送信せず Authorization Codeを取得する Authorization Code Flow
  113. 113. 116 Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 11.Access Token/ID Token 12.Access Token 13.Claims 10.Tokenリクエスト(Authorization Code) 悪意あるユーザーのIDで取得した Access Tokenを含んだredirect_uriを フィッシングサイトなどでアクセスさせる 14.属性情報取得 ログイン完了 End-User 7.redirect_uri 8.URLクリック 乗っ取らせてサービスを利⽤させ ユーザーの情報を窃取する 9.悪意あるユーザーの Authorization Code Authorization Code Flow
  114. 114. state • OAuth 2.0にはCSRF対策として「state」パラメーターが 定義されている • RPがAuthorizationリクエストで指定したstate値と Authorizationレスポンスで認可コードと同時に返却される state値の⼀致を検証することで認可コードの置き換えに夜 乗っ取らせを防⽌する 117
  115. 115. 118 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト(state=xyz) 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 9.Access Token 10.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code + state=xyz 7.Tokenリクエスト(Authorization Code) 11.属性情報取得 ログイン完了 RPのセッション (HTTPOnlyのCookieなど) に紐付けたstate値を送信 Authorization Codeと共にstate値が返却される セッションに紐づけたstate値と⼀致するか 検証することでCSRFを防⽌ Authorization Code Flow
  116. 116. 119 Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 11.Access Token/ID Token 12.Access Token 13.Claims 10.Tokenリクエスト(Authorization Code) 14.属性情報取得 ログイン完了 End-User 7.redirect_uri 8.URLクリック 被害者のセッションに紐づくstate値 (サービスのAuthorizationリクエストに アクセスしていなければセッションもない) と⼀致しないため置き換えを検知できる 9.悪意あるユーザーの Authorization Code + state=abc Authorization Code Flow
  117. 117. 【演習】CSRF攻撃体験 120 CSRF攻撃を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice02
  118. 118. 【演習】CSRF攻撃対策 121 CSRF攻撃対策のサンプルコード https://github.com/kura-lab/seccamp2019/tree/master/practice02-answer
  119. 119. OpenID Connectを理解しよう ID Tokenの解説
  120. 120. ID Tokenとは • ユーザー認証情報を含む改ざん検知⽤の署名付きToken • JSON Web Token(JWT)フォーマット • IdPが認証したユーザーの認証情報を含めRPが検証し RP側のセッション管理に⽤いる 126 ID
  121. 121. JSON Web Token(JWT) • JSONをBase64urlエンコード(URL SafeなBase64エンコード) したシグネチャ(ハッシュ値もしくはデジタル署名)付きトークン • ヘッダー・ペイロード・シグネチャの3つから構成される • シグネチャはハッシュ(HMAC)と 公開鍵暗号(RSA・ECDSA)をサポート • JWTと表記して「jot(ジョット)」と発⾳する 127 Jot down
  122. 122. ID Tokenの解説 ID Tokenの検証
  123. 123. 130 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleH AiOjEzMDA4MTkzODAsDQogImh0dHA 6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp 0cnVlfQ.dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk ID Token
  124. 124. 131 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature ピリオド区切りの3つの部位から構成される
  125. 125. 132 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature Base64エンコードは「/」や「=」が 含まれURL Safeでないため Base64urlエンコードが利⽤されている
  126. 126. 133 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 { "type": "JWT", "alg": "RS256" } Header Signature Base64urlデコード 置換前 置換後 “-” “+” “/” “_” (データ⻑ % 4)の 数だけ”=”をパディング Base64urlデコード Base64デコード
  127. 127. 134 { "type": "JWT", "alg": "RS256" } type: JSON Web Token
  128. 128. 135 { "type": "JWT", "alg": "RS256" } algorithm: Signatureのアルゴリズム RS256=RSA SHA-256 alg アルゴリズム 実装要求 HS256 HMAC SHA-256 RS256 RSA SHA-256 推奨 ES256 ECDSA SHA-256 推奨 JWT サポートアルゴリズム
  129. 129. 136 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload SignatureHeader + ”.” + Payloadを ⼊⼒データとする
  130. 130. 137 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature 検証結果が正しければ PayloadのClaim(属性情報)を参照する typのアルゴリズムで⼊⼒データとSignatureと IdPが公開している公開鍵をつかって改ざんを検証
  131. 131. 138 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } Payload Base64urlデコード
  132. 132. 139 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } issuer ID Tokenの発⾏社(IdP)
  133. 133. 140 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } subject ユーザー識別⼦(認証の対象者)
  134. 134. 141 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } audience Client ID(ID Tokenの発⾏先)
  135. 135. 142 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } 発⾏社(iss)が どのRP(aud)に対して どのユーザー(sub)を認証した のかを⽰している RP側でこれらの値を検証することで トークン置き換え攻撃を防⽌可能
  136. 136. OpenID Connectを理解しよう リプレイ攻撃対策
  137. 137. リプレイ攻撃 ⼀般的な場合 • 有効なデータ転送が故意または不正に繰り返し/遅延されるこ とによる攻撃 • IPパケットの置換によるDNS偽装の⼀部のように、発信者や攻 撃者がデータを傍受し再送信することによって実⾏される OpenID Connectの場合 • ID Tokenを傍受し不正ログインを試みる 144
  138. 138. 145 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 Implicit Flow リプレイ攻撃の 対象になる部分は どこでしょう︖
  139. 139. 146 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 通信経路から傍受されたID Tokenを 受け⼊れてしまう Implicit Flow
  140. 140. 147 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token 4.同意画⾯ Proxyなどを⽤いて ID Tokenを傍受 8.ログイン完了 7.ID Token Implicit Flow
  141. 141. nonce (number used once) • OpenID ConnectにはID Tokenのリプレイ攻撃対策として 「nonce」パラメーターが定義されている • RPがAuthorizationリクエストで指定したnonce値と 返却されるID Tokenの内部に含まれるnonce値の ⼀致を検証することで繰り返し送信されるID Tokenの リプレイ攻撃を防⽌する 148
  142. 142. ID Token Payload 149 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } リプレイ攻撃対策のnonce
  143. 143. 150 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト(nonce=xyz) 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token 9.Claims 4.同意画⾯ 10.属性情報取得完了 7.ログイン完了 RPのセッション (HTTPOnlyのCookieなど) に紐付けた値を送信 nonce値を含んだID Tokenが返却される セッションに紐づけたnonce値と⼀致するか 検証することでリプレイ攻撃を防⽌ 6.Access Token/ID Token(nonce=xyz) Implicit Flow
  144. 144. 151 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 6.Access Token/ID Token(nonce=123) 4.同意画⾯ 8.ログイン完了 7.ID Token(nonce=123) 被害者のセッションに紐づくnonce値 (サービスのAuthorizationリクエストに アクセスしていなければセッションもない) と⼀致しないため置き換えを検知できる Implicit Flow
  145. 145. nonceの検証 • nonceの検証はID Tokenの再送が起こりうるケースのみ必須 • クライアントサイドでID Tokenを受け取るHybridフローの場合は必須 • Authorization CodeフローのRPとIdPのサーバー間で安全に ID Tokenが送受信される場合にはnonceの検証は任意でよい 152
  146. 146. 【演習】ユーザー認証(ID Tokenの検証)・リプレイ攻撃対策 153 ユーザー認証のためのID Tokenの検証と リプレイ攻撃の対策をしてみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice03
  147. 147. 【演習】ユーザー認証(ID Tokenの検証)・リプレイ攻撃対策 154 ユーザー認証(ID Tokenの検証)・リプレイ攻撃対策の サンプルコード https://github.com/kura-lab/seccamp2019/tree/master/practice03-answer
  148. 148. OpenID Connectを理解しよう UserInfoエンドポイントの解説
  149. 149. UserInfoエンドポイント • ⽒名や住所、メールアドレスなどの属性情報を標準仕様化 して取得しやすいように属性情報(Claim)を定義 • 関連した属性情報ごとにアクセス制限としてScopeを定義 • RPのサービスに必要な属性情報だけをIdPに要求すること が可能 156
  150. 150. 定義されている属性情報 157 Claim Scope 説明 sub - ユーザー識別⼦ name profile ⽒名 give_name profile 名 family_name profile 姓 middle_name profile ミドルネーム nickname profile ニックネーム preferred_ username profile 簡略名 Claim Scope 説明 profile profile プロフィール情報の URL picture profile プロフィール画像の URL website profile サイトURL gender profile 性別 birthdate profile ⽣年⽉⽇ email email メールアドレス email_verified email メールアドレスの 検証済みの有無
  151. 151. 定義されている属性情報 158 Claim Scope 説明 zoneinfo profile タイムゾーン locale profile 国コード update profile 属性情報更新⽇時 phone_number phone 電話番号 phone_number _verified phone 電話番号の検証済み の有無 Claim Scope 説明 address/country address 国コード address/postal_code address 郵便番号 address/region address 都道府県 address/locality address 市区町村 address/formatted address 住所
  152. 152. 属性情報取得の留意点 • 全Scopeを指定すればすべての属性情報を取得することが できる • 関連した属性情報ごとにScopeがわけられているのは、 サービスに必要なものに絞って取得できるにしている • 不要な属性情報の取得はユーザーの不安につながるため 注意が必要 159
  153. 153. OpenID Connectを理解しよう ユーザー識別⼦
  154. 154. 【演習】メールアドレス •UserInfoなどからユーザーのメールアドレスを 取得可能 •取得したメールアドレスをユーザー識別⼦とする とどのような懸念点が発⽣するか考えてみよう 161
  155. 155. 162 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 8.Access Token/ID Token 11.Access Token 12.Claims(E-mail Address) 4.同意画⾯ 0-2.処理開始 6.Authorization Code 7.Tokenリクエスト(Authorization Code) 13.属性情報取得完了 9.ログインセッション 発⾏ 10.ログイン完了 Authorization Code Flow IdPが返却するメールアドレスが RPに登録されているものと 異なるものに変更されると 別のユーザーとして 取り扱ってしまう懸念が⽣じる IdPの仕様によってはユーザーが登録している メールアドレスを変更できる場合がある
  156. 156. 【解説】メールアドレス • IdPによっては変更されない固定のメールアドレスを返却する 場合があるが、ユーザーとのコミュニケーションチャネルと して利⽤するのがよい • OpenID Connectの仕様としては、メールアドレスが 変更されてもユーザー認証ができるように、IdPで管理される IDに対してユニークで変更されることのないユーザー識別⼦ (sub)の値を⽤いるべきである 163
  157. 157. 【演習】PPID •PPID=Pairwise Pseudonymous Identifier •仮名化ID •クライアント(RP)ごとに異なるユーザー識別⼦ •PPIDにすることの利点を考えてみよう 164
  158. 158. 【解説】PPID • IdPが各RPに対して共通のユーザー識別⼦を返却すると 複数のRP間でユーザーの同意なしでもターゲティングを ⽬的とした名寄せができてしまう 165 sub: 共通ユーザー識別⼦ IdPやユーザーの意図しない 名寄せができてしまう RPその1 共通ユーザー識別⼦ RPその2 IdP sub: 共通ユーザー識別⼦
  159. 159. 【解説】PPID • RPでのID管理基盤の漏洩が起こった際には漏洩元を特定し 他RPへの影響を最⼩限にすることができる • IdPはユーザーを名寄せ防⽌のために PPIDを検討すべきである 166 sub: PPID X RPその1 RPその2 IdP sub: PPID Y PPID X 漏洩してもPPIDから漏洩したRPを特定し 他のRPの洗い替えなどが不要となる ユーザー識別⼦が 異なるため 名寄せができない
  160. 160. OpenID Connectを理解しよう Hybrid Flowの解説
  161. 161. Hybrid Flow • Authorization EndpointからAccess TokenとID Tokenが ブラウザー上のClientに直接返却される • さらにAuthorization Codeが返却され、Token Endpointで Access TokenとID TokenがBack-End Serverに返却される 168
  162. 162. 169 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル 情報⼊⼒ 5.同意 12.Access Token/ID Token 15.Access Token 16.Claims 4.同意画⾯ 0-2.処理開始 6.Authorization Code/Access Token/ID Token 11.Tokenリクエスト(Authorization Code) 17.属性情報取得完了 13.ログインセッション 発⾏ 14.ログイン完了 10.Authorization Code 8.Access Token 7.クライアントサイド ログイン完了 9.クライアントサイド 属性情報取得完了
  163. 163. Hybrid Flowの利⽤にあたって • Authorization Codeをサーバーへ送信する前に、Clientサイドで ユーザー認証をいち早く完了させたい場合などに利⽤できる • ただし、⼤抵の3rd PartyアプリケーションはID管理をBack-End Serverで⾏うため、Clientサイドのユーザー認証は不要である • Hybrid Flowを導⼊する前に、Authorization Code Flowで ID連携の要件を満たすことができるか検討すべきである 170
  164. 164. OpenID Connectを理解しよう OpenID Certificationの紹介
  165. 165. OpenID Foundationでは IdPとRPの認定プログラムを実施中 Google・Microsoft・NRI・ NEC・Yahoo! JAPANなどが IdPの認定を取得済み RPの認定製品も増えて⽣きている
  166. 166. 173 RPライブラリーや製品を実装して OpenIDの認定を取得できる
  167. 167. まとめ
  168. 168. まとめ 1. はじめに • FIDOとOpenID Connectの概要 2. 認証と認可を理解しよう 3. FIDOを理解しよう 1. FIDO UAF 2. FIDO U2F 3. FIDO2(CTAP/WebAuthn) 4. FIDO2登録フロー 5. FIDO2認証フロー 4. OpenID Connectを理解しよう 1. Implicit Flowの解説 2. トークン置き換え攻撃対策 3. ユーザー識別⼦による脆弱な認証 4. Authorization Code Flowの解説 5. CSRF対策 6. ID Tokenの解説 7. リプレイ攻撃対策 8. UserInfoエンドポイントの解説 9. ユーザー識別⼦ 10. Hybrid Flowの解説 11. OpenID Certificationの紹介 5. まとめ 175
  169. 169. まとめ •本⽇の講義・演習を振り返ってみましょう •学んだこと、さらに知りたいことや疑問点などを まとめてましょう 176
  170. 170. ご清聴ありがとうございました

×