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

1. セキュリティ・キャンプ全国⼤会2019 専⾨講義選択コース B4 認証の課題とID連携の実装〜ハンズオン〜 2019年8⽉15⽇ OpenID ファウンデーション・ジャパン倉林雅

2. プロフィール倉林雅（くらはやしまさる） OpenID ファウンデーション・ジャパン理事 / エバンジェリストヤフー株式会社認証技術⿊帯 / ID・セキュリティエンジニア https://twitter.com/kura_lab 2

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. はじめに FIDOとOpenID Connectの概要

6. FIDOが提供する機能 6 簡単にいうと「セキュリティとUXを両⽴したユーザー認証」

7. 7 ログインが求められる

8. 8 パスワードや確認コードを⼊⼒せずに⽣体認証などでログイン

9. OpenID Connectが提供する機能 9 簡単にいうと「ユーザー認証」と「属性情報取得」

10. 10 所持しているIDのサービスを選択

11. 11 ログインをする

12. 12 同意をする

13. 13 情報がプリセットされる

14. 本⽇のゴール 14 認証・認可の仕組みを理解する ID連携の実装を通じてセキュリティリスクと対策を学ぶ

15. 認証と認可を理解しよう

16. 「認証」と「認可」 16 「認証」を意味する英単語は2つ存在する

17. 2種類の「認証」 17 ⽤語説明 Authentication 認証する側とされる側が事前に共有している情報を確認すること例）IDとパスワードでユーザーを認証する Certification 信頼できる機関（認証局）が証明書をもとに「持ち主」の正当性を確認すること例）クレジットカード会社が発⾏したカードを店舗に提⽰して所有者を認証する

18. 2種類の「認証」 18 ⽤語説明 Authentication 認証する側とされる側が事前に共有している情報を確認すること例）IDとパスワードでユーザーを認証する Certification 信頼できる機関（認証局）が証明書をもとに「持ち主」の正当性を確認すること例）クレジットカード会社が発⾏したカードを店舗に提⽰して所有者を認証する OpenID Connectのフローにでてくる認証は「Authentication」

19. 「認証」と「認可」 19 「認証」と「認可」の違い

20. 2種類の「認証」 20 ⽤語説明認証（Authentication/AuthN）アクセスしている相⼿の正当性をチェックして正規の利⽤者であるかを確認する認可（Authorization/AuthZ）認証済みの利⽤者にサービスの利⽤やリソースへのアクセスなどの権限を与えること

21. ID連携・認証・プロビジョニング 21 Attributes Single Sign-On Federation Authentication Provisioning OpenID Connect SAML FIDO SCIM

22. ID連携・認証・プロビジョニング 22 Attributes Single Sign-On Federation Authentication Provisioning OpenID Connect SAML FIDO SCIMユーザーの認証とその結果を連携するID連携は仕様が分かれており補完関係にある

23. FIDOを理解しよう

24. ⽤語集 • クレデンシャル情報 • パスワードや⽣体情報などユーザー認証に必要な情報 • RP (Relying Party) • ユーザーのIDを登録、認証し管理するサーバー（FIDO2 Server） • Authenticator（認証器） • 秘密鍵・公開鍵のペアを⽣成し、RPへ送信する署名を⽣成する • Client-Side • Authenticatorやユーザー端末などの総称 • WebAuthn Client • ブラウザーなどのUser Agent 24

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. FIDOとは • FIDO = Fast IDentity Online（⾼速なオンラインID認証） • 顔や指紋のクレデンシャル情報をサーバーへ送らず保存しない • ⽣体認証などのさまざまな認証⽅法に対応 26

27. FIDOで提供している仕様 27 UAF U2F FIDO2 CTAP WebAuthn FIDO Allianceではパスワードレス型、パスワード補完型、 FIDO認証を拡⼤するための拡張仕様を提供している

28. FIDO UAF •UAF = Universal Authentication Framework •主にスマートフォン（アプリ）を想定したパスワードレス型の認証 •所持認証 + ⽣体認証など 28 UAF

29. FIDO U2F •U2F = Universal 2nd Factor •主にPCのWebブラウザーで⼆要素認証を想定したパスワード補完型の認証 •記憶認証 + 所持認証 29 U2F

30. FIDO2 • FIDO2の仕様は、FIDO AllianceのClient-to- Authenticator Protocol(CTAP)とW3CのWebAuthn から構成される • スマートフォンとPCを想定し、⼀般的なデバイス（USB、BLE、NFCなどが利⽤できる端末）を活⽤した認証 30 FIDO2 CTAP WebAuthn

31. • IDとクレデンシャル情報（パスワードなど）を認証サーバーへ送信 • 認証サーバーはIDとクレデンシャル情報を検証し認証 • パスワードなどを⼊⼒する場合、通信経路での漏洩やフィッシングでの窃取の懸念あり • クレデンシャル情報を認証サーバーで保存するため漏洩のリスクは⼤きい従来の認証モデル 31 ユーザー認証サーバークレデンシャル情報（パスワード）クレデンシャル情報の検証クレデンシャル情報の⼊⼒クレデンシャル情報（パスワード）

32. • デバイスの認証器(Authenticator)が本⼈性を検証 • 検証結果に秘密鍵で署名し認証サーバーに送信 • 認証サーバーで公開鍵を使って署名を検証しユーザーを認証 • クレデンシャル情報が流れないため、パスワードのフィッシング耐性あり FIDO認証モデル 32 ユーザー認証サーバー検証結果（署名）秘密鍵公開鍵クレデンシャル情報の⼊⼒検証結果の妥当性を確認

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. FIDOを理解しよう FIDO2登録フロー

35. FIDO2登録フロー 35 End-User Authenticator Web Browser (WebAuthn Client) Relying Party (FIDO2 Server) Client-Side FIDOはサーバーがRP

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. 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. 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. 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. 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. FIDOを理解しよう FIDO2認証フロー

42. FIDO2認証フロー 42 End-User Relying Party (FIDO2 Server) FIDOはサーバーがRP Authenticator Web Browser (WebAuthn Client) Client-Side

43. FIDO2認証フロー 43 End-User Relying Party (FIDO2 Server) 0-2.ログインID 登録しているログインIDを指定して認証開始 Authenticator Web Browser (WebAuthn Client) Client-Side 0-1.ログイン開始

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. 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. 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. 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. OpenID Connectを理解しよう

49. ⽤語集 • IdP (Identity Provider) • 認証を⾏ってID、属性情報を提供する • RP (Relying Party) • IdPの認証を利⽤してEnd-Userにサービスを提供する • Claim • IdPやEnd-Userなどの属性情報 49

50. ⽤語集 • IdP (Identity Provider) • 認証を⾏ってID、属性情報を提供する • RP (Relying Party) • IdPの認証を利⽤してEnd-Userにサービスを提供する • Claim • IdPやEnd-Userなどの属性情報 50 OpenID Connectでは IDを管理・認証するサーバーはRPではない認証結果を受け取る側が RPと覚えとくとよい

51. OpenIDとは • OpenIDはユーザーの認証の技術 • （OpenID AXで属性を取得する拡張はある） 51

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. OAuthとは • OAuth 1.0とOAuth 2.0はユーザーの認可の技術 • ユーザーのリソースアクセス（Web API）が⽬的 53

54. OAuth • 2009年 • OAuth 1.0a • 2010年 • OAuth 1.0 Protocol • 2012年 • OAuth 2.0 Authorization Framework 54 オーオースッ

55. OpenID Connectとは • ユーザーの認証と認可を兼ね備えた技術 • OpenIDとは異なる技術でOAuth 2.0を拡張したプロトコル • 2014年2⽉にローンチ 55

56. 56

57. 57 OpenID ConnectはOAuth 2.0や JSON Web Tokenなどの技術で構成されている

58. OpenID Connect 58 Web API連携・ユーザー認証・ユーザー属性情報取得に必要な仕様が定義れている認可認証属性取得 OAuth 2.0 JSON Web Token

59. OpenID Connectの技術 OpenID Connectには Webアプリケーションとセキュリティの技術が満載 59

60. OpenID Connectの技術 1. Locationヘッダー（リダイレクト） 2. CSRF対策 3. HTTP通信 4. Basic認証（トークン発⾏時のクライアント認証） 5. JSON Web Token 6. リプレイ攻撃対策 7. Bearer Token など 60

61. OpenID Connectの技術 RPを実装することで基礎から応⽤までのWeb技術を学ぶことができる 61

62. OpenID Connectを理解しよう Implicit Flowの解説

63. Implicit Flow • 主にスクリプト⾔語を⽤いて実装されブラウザ上で動作するClientによって使⽤される • Access TokenとID Tokenは、Clientに直接返却され End-UserとEnd-UserのUser Agentにアクセスするアプリケーションに露出する可能性がある • Authorization Serverはクライアント認証を⾏わない 63

64. 64 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo Implicit Flow OpenID Connectは ClientがRP サーバーはIdP

65. 65 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 Implicit Flow

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 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0.処理開始 1.Authorizationリクエスト 2.ログイン画⾯ 3.クレデンシャル情報⼊⼒ Implicit Flow パスワードやSMSの確認コード、 FIDOなどでユーザーを認証

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 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 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 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 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 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 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 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 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. OpenID Connectを理解しようトークン置き換え攻撃対策

78. OAuth認証のリスク 78 リスクトークン置き換え攻撃事象 Access Tokenを置き換えることで悪意あるユーザーとして認証させて「乗っ取らせ」を⾏いユーザー情報を登録させるなどのセキュリティホールを⽣む可能性あり対策 Access Tokenの置き換えの⼝をつくらない受け取ったTokenの発⾏対象のクライアントを検証する

79. OAuth認証のリスク 79 リスクトークン置き換え攻撃事象 Access Tokenを置き換えることで悪意あるユーザーとして認証させて「乗っ取らせ」を⾏いユーザー情報を登録させるなどのセキュリティホールを⽣む可能性あり対策 Access Tokenの置き換えの⼝をつくらない受け取ったTokenの発⾏対象のクライアントを検証する OAuthは「認可」の仕組みであり「認証」のためのセキュリティ対策が仕様に組み込まれていない

80. トークン置き換え攻撃 • クライアントで取得したAccess Tokenをサーバーへ送信しユーザー識別⼦を取得して認証する • クライアントとサーバー間でのAccess Tokenの受け渡しは仕様に定義されていない • サーバーへ送信するAccess Tokenを別のものに置き換えることで別のユーザーでログインできてしまう脆弱性となりうる 80

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 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 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. 【演習準備】Golang実⾏環境セットアップ 84 以下の⼿順に従って演習の準備をしましょう https://github.com/kura-lab/seccamp2019/tree/master/practice00

85. 【演習】トークン置き換え攻撃体験 85 トークン置き換え攻撃を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice01-1

86. トークン置き換え攻撃クライアントサイドで取得した Access Tokenをサーバーサイドへ送信するユーザー認証は実装してはならない 86

87. OpenID Connectを理解しようユーザー識別⼦による脆弱な認証

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 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 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 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 ユーザー識別⼦による脆弱な認証を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice01-2

93. ユーザー識別⼦による脆弱な認証 OpenID Connectは「認可」のOAuth 2.0にユーザーの「認証」の機能を追加 93

94. ユーザー識別⼦による脆弱な認証安易な独⾃実装は脆弱性につながるためユースケースと対応する各フローを理解し OpenID Connectを正しく実装しましょう 94

95. OpenID Connectを理解しよう Authorization Code Flowの解説

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 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo Authorization Code Flow Authorization Code Flowの場合 IdPの認証結果を受け取るのは Back-End Server

98. 98 End-User Client (User Agent) Back-End Server AuthN/AuthZ Server UserInfo 0-1.処理開始 0-2.処理開始 Authorization Code Flow

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 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 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 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 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 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 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 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 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. OpenID Connectを理解しよう CSRF対策

109. CSRF (Cross-Site Request Forgery) ⼀般的な場合 • 別のサイトに⽤意したコンテンツ上の罠のリンクを踏ませることなどをきっかけとして、インターネットショッピングの最終決済や退会などのWebアプリケーションの重要な処理を呼び出すようユーザーを誘導する攻撃 OAuth 2.0/OpenID Connectの場合 • 悪意あるユーザーの認可コードを被害者に乗っ取らせ情報を窃取する 112

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. 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. 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. 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. state • OAuth 2.0にはCSRF対策として「state」パラメーターが定義されている • RPがAuthorizationリクエストで指定したstate値と Authorizationレスポンスで認可コードと同時に返却される state値の⼀致を検証することで認可コードの置き換えに夜乗っ取らせを防⽌する 117

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. 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. 【演習】CSRF攻撃体験 120 CSRF攻撃を体験してみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice02

118. 【演習】CSRF攻撃対策 121 CSRF攻撃対策のサンプルコード https://github.com/kura-lab/seccamp2019/tree/master/practice02-answer

119. OpenID Connectを理解しよう ID Tokenの解説

120. ID Tokenとは • ユーザー認証情報を含む改ざん検知⽤の署名付きToken • JSON Web Token(JWT)フォーマット • IdPが認証したユーザーの認証情報を含めRPが検証し RP側のセッション管理に⽤いる 126 ID

121. JSON Web Token(JWT) • JSONをBase64urlエンコード（URL SafeなBase64エンコード）したシグネチャ（ハッシュ値もしくはデジタル署名）付きトークン • ヘッダー・ペイロード・シグネチャの3つから構成される • シグネチャはハッシュ（HMAC）と公開鍵暗号（RSA・ECDSA）をサポート • JWTと表記して「jot（ジョット）」と発⾳する 127 Jot down

122. ID Tokenの解説 ID Tokenの検証

123. 130 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleH AiOjEzMDA4MTkzODAsDQogImh0dHA 6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp 0cnVlfQ.dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk ID Token

124. 131 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature ピリオド区切りの3つの部位から構成される

125. 132 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature Base64エンコードは「/」や「=」が含まれURL Safeでないため Base64urlエンコードが利⽤されている

126. 133 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 { "type": "JWT", "alg": "RS256" } Header Signature Base64urlデコード置換前置換後 “-” “+” “/” “_” （データ⻑ % 4）の数だけ”=”をパディング Base64urlデコード Base64デコード

127. 134 { "type": "JWT", "alg": "RS256" } type: JSON Web Token

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. 136 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload SignatureHeader + ”.” + Payloadを⼊⼒データとする

130. 137 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIU zI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzM DA4MTkzODAsDQogImh0dHA6Ly9leG FtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEj Xk Header Payload Signature 検証結果が正しければ PayloadのClaim（属性情報）を参照する typのアルゴリズムで⼊⼒データとSignatureと IdPが公開している公開鍵をつかって改ざんを検証

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. 139 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } issuer ID Tokenの発⾏社（IdP）

133. 140 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } subject ユーザー識別⼦（認証の対象者）

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. 142 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } 発⾏社（iss）がどのRP（aud）に対してどのユーザー（sub）を認証したのかを⽰している RP側でこれらの値を検証することでトークン置き換え攻撃を防⽌可能

136. OpenID Connectを理解しようリプレイ攻撃対策

137. リプレイ攻撃⼀般的な場合 • 有効なデータ転送が故意または不正に繰り返し/遅延されることによる攻撃 • IPパケットの置換によるDNS偽装の⼀部のように、発信者や攻撃者がデータを傍受し再送信することによって実⾏される OpenID Connectの場合 • ID Tokenを傍受し不正ログインを試みる 144

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. 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. 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. nonce (number used once) • OpenID ConnectにはID Tokenのリプレイ攻撃対策として「nonce」パラメーターが定義されている • RPがAuthorizationリクエストで指定したnonce値と返却されるID Tokenの内部に含まれるnonce値の⼀致を検証することで繰り返し送信されるID Tokenのリプレイ攻撃を防⽌する 148

142. ID Token Payload 149 { "iss":"https://idp.example.com", "sub":"123456789", "aud":"abcdefg", "nonce":"xyz", "iat":1291836800, "exp":1300819380, "nonce":"xyz..." } リプレイ攻撃対策のnonce

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. 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. nonceの検証 • nonceの検証はID Tokenの再送が起こりうるケースのみ必須 • クライアントサイドでID Tokenを受け取るHybridフローの場合は必須 • Authorization CodeフローのRPとIdPのサーバー間で安全に ID Tokenが送受信される場合にはnonceの検証は任意でよい 152

146. 【演習】ユーザー認証（ID Tokenの検証）・リプレイ攻撃対策 153 ユーザー認証のためのID Tokenの検証とリプレイ攻撃の対策をしてみましょう https://github.com/kura-lab/seccamp2019/tree/master/practice03

147. 【演習】ユーザー認証（ID Tokenの検証）・リプレイ攻撃対策 154 ユーザー認証（ID Tokenの検証）・リプレイ攻撃対策のサンプルコード https://github.com/kura-lab/seccamp2019/tree/master/practice03-answer

148. OpenID Connectを理解しよう UserInfoエンドポイントの解説

149. UserInfoエンドポイント • ⽒名や住所、メールアドレスなどの属性情報を標準仕様化して取得しやすいように属性情報(Claim)を定義 • 関連した属性情報ごとにアクセス制限としてScopeを定義 • RPのサービスに必要な属性情報だけをIdPに要求することが可能 156

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. 定義されている属性情報 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. 属性情報取得の留意点 • 全Scopeを指定すればすべての属性情報を取得することができる • 関連した属性情報ごとにScopeがわけられているのは、サービスに必要なものに絞って取得できるにしている • 不要な属性情報の取得はユーザーの不安につながるため注意が必要 159

153. OpenID Connectを理解しようユーザー識別⼦

154. 【演習】メールアドレス •UserInfoなどからユーザーのメールアドレスを取得可能 •取得したメールアドレスをユーザー識別⼦とするとどのような懸念点が発⽣するか考えてみよう 161

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. 【解説】メールアドレス • IdPによっては変更されない固定のメールアドレスを返却する場合があるが、ユーザーとのコミュニケーションチャネルとして利⽤するのがよい • OpenID Connectの仕様としては、メールアドレスが変更されてもユーザー認証ができるように、IdPで管理される IDに対してユニークで変更されることのないユーザー識別⼦ (sub)の値を⽤いるべきである 163

157. 【演習】PPID •PPID=Pairwise Pseudonymous Identifier •仮名化ID •クライアント(RP)ごとに異なるユーザー識別⼦ •PPIDにすることの利点を考えてみよう 164

158. 【解説】PPID • IdPが各RPに対して共通のユーザー識別⼦を返却すると複数のRP間でユーザーの同意なしでもターゲティングを⽬的とした名寄せができてしまう 165 sub: 共通ユーザー識別⼦ IdPやユーザーの意図しない名寄せができてしまう RPその1 共通ユーザー識別⼦ RPその2 IdP sub: 共通ユーザー識別⼦

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. OpenID Connectを理解しよう Hybrid Flowの解説

161. Hybrid Flow • Authorization EndpointからAccess TokenとID Tokenがブラウザー上のClientに直接返却される • さらにAuthorization Codeが返却され、Token Endpointで Access TokenとID TokenがBack-End Serverに返却される 168

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. Hybrid Flowの利⽤にあたって • Authorization Codeをサーバーへ送信する前に、Clientサイドでユーザー認証をいち早く完了させたい場合などに利⽤できる • ただし、⼤抵の3rd PartyアプリケーションはID管理をBack-End Serverで⾏うため、Clientサイドのユーザー認証は不要である • Hybrid Flowを導⼊する前に、Authorization Code Flowで ID連携の要件を満たすことができるか検討すべきである 170

164. OpenID Connectを理解しよう OpenID Certificationの紹介

165. OpenID Foundationでは IdPとRPの認定プログラムを実施中 Google・Microsoft・NRI・ NEC・Yahoo! JAPANなどが IdPの認定を取得済み RPの認定製品も増えて⽣きている

166. 173 RPライブラリーや製品を実装して OpenIDの認定を取得できる

167. まとめ

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. まとめ •本⽇の講義・演習を振り返ってみましょう •学んだこと、さらに知りたいことや疑問点などをまとめてましょう 176

170. ご清聴ありがとうございました

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

Masaru Kurahayashi