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

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

3.
3

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.
ご清聴ありがとうございました