KeycloakでFAPIに対応した高セキュリティなAPIを公開する

© Hitachi, Ltd. 2022. All rights reserved.
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
CloudNative Days Tokyo 2022
株式会社日立製作所
田畑義之

1
自己紹介
田畑義之 (たばたよしゆき)
 株式会社日立製作所アーキテクチャセンタ
 ソフトウェアエンジニア
 GitHub: @y-tabata
• 認証認可やAPI関連分野のソリューション開発&コンサルティング
 金融、公共、社会、産業分野における
API管理基盤や認証認可システムの導入支援
• 認証認可・API管理関連のOSSへのコントリビュート
 Keycloak (IAMのOSS)
 3scale (API管理のOSS)
• 情報発信
 Keycloak書籍
 ThinkIT/@ITでのWeb記事連載
 Apidays/OAuth Security Workshop/CloudNative Daysなど、国内外のイベントでの登壇

2
セッション概要
• FAPI (Financial-grade API)という高セキュリティなAPIを公開するための仕様があります。
• システムのセキュリティは高ければ高いほど望ましいですが、実案件では対応コストやユー
ザビリティとの
トレードオフを見ていかないといけません。
 一方で、FAPIに準拠しないにしても、どんな攻撃のリスクがあるかを知り、自システムで
はどうやって対策
できるかを考えておくことは大切です。
低い対応コスト/
高いユーザビリティ
高いセキュリティレベル
• FAPIの概要のご説明
• FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介
• IAMを実現するOSSであるKeycloakにおけるFAPI対応のご紹介
本セッションでは・・・

Contents
3
1. FAPIとは
2. FAPIに準拠することで防げる攻撃～8選～
3. KeycloakにおけるFAPI対応

Contents
4
1. FAPIとは

5
FAPIとは
• Financial-grade API (FAPI)セキュリティプロファイルは、「API認可」のプロトコルとし
てよく使われるOAuth 2.0や「SSO」のプロトコルとしてよく使われるOpenID Connect
(OIDC)をベースに、高い
レベルのセキュリティを必要とするあらゆる市場領域のAPIに適用するためのOAuth 2.0や
OIDCの
セキュアな使い方を定義している。
Financial-grade API
Security Profile 1.0
Part 2: Advanced
RFC 7519: JSON
Web Token (JWT)
RFC 7636: Proof Key
for Code Exchange by
OAuth Public Clients
RFC 6819: OAuth 2.0
Threat Model and
Security Considerations
RFC 6750: The OAuth 2.0
Authorization Framework:
Bearer Token Usage
RFC 6749: The OAuth
2.0 Authorization
Framework
OpenID Connect
Core 1.0
RFC 8705: OAuth 2.0 Mutual-
TLS Client Authentication and
Certificate-Bound Access Tokens
RFC 9126: OAuth 2.0
Pushed Authorization
Requests
Financial-grade API: JWT
Secured Authorization Response
Mode for OAuth 2.0 (JARM)

Contents
6
1. FAPIとは

7
前提
• OAuth 2.0/OIDCで最も推奨される認可コードフローを前提とします(ハイブリッドフロー
を含む)。
※インプリシットフローやリソースオーナパスワードクレデンシャルズフローだと、説明すべき攻撃方法の数が多くなってしまうため。
正当なユーザクライアントリソースサーバ
認可サーバ
アクセス
認可リクエスト
ログイン画面
ログイン
認可レスポンス
トークンリクエスト
トークンレスポンス
APIリクエスト
APIレスポンス
画面表示

8
まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~
1. 正当なユーザとしてクライアントにログインすること。
2. 正当なユーザのリソースにアクセスすること。
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
※参考: FAPI 2.0 Attacker Model
https://openid.net/specs/fapi-2_0-attacker-model-00.html

9
正当なユーザ
攻撃者
クライアント
正当なユーザ
正当なユーザとしてログインすることで以下のようなことができる。
• クライアントに設定している情報からの、正当なユーザの個人情報の取得
→住所や電話番号、プライベートな写真の取得など。
• 正当なユーザの周辺のユーザへの攻撃
→「友達」として登録されているユーザへのプリペイドカード番号の要求など。

10
正当なユーザ
攻撃者
クライアント正当なユーザ
リソースサーバ
正当なユーザのリソースにアクセスすることで以下のようなことができる。
• リソースサーバに保存している情報からの、正当なユーザの個人情報の取得
→保存しているドキュメントや写真、動画の取得など。
• 金融取引をトリガーするために利用できるAPIのコール
→正当なユーザの口座から攻撃者の口座への送金のリクエストなど。

11
正当なユーザ
攻撃者
クライアント
攻撃者
攻撃者
正当なユーザに攻撃者としてログインさせたり、攻撃者のリソースにアクセスさせることで以下のようなことができる。
• 攻撃者アカウントへ登録された正当なユーザの情報の取得
→正当なユーザが誤って攻撃者のアカウントへ登録してしまった個人情報や口座情報の取得など。
• 正当なユーザのアカウント情報を用いた他システムへのログイン
→正当なユーザが誤って攻撃者のアカウントへ紐づけてしまった他システムのアカウントを用いたログインなど。

12
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる？ ~
1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。
2. 正当なユーザにリンクを送付して、そこに訪問させることができる。
3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。
4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができる。
5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。
6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレスポ
ンスを改ざんすることができる。
7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加し、認
可サーバからトークンを取得することができる。
※参考: FAPI 2.0 Attacker Model
https://openid.net/specs/fapi-2_0-attacker-model-00.html

13
1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。
正当なユーザ
攻撃者
クライアント
認可サーバ
自作メッセージを
送付
改ざんした
メッセージを送付
正当なメッセージを
送付

14
2. 正当なユーザにリンクを送付して、そこに訪問させることができる。
正当なユーザ
攻撃者
クライアント
認可サーバ
攻撃者のサイト
リンクを
送付
訪問

15
不正なWiFiアクセスポイントや
侵害したネットワーク内
3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。
正当なユーザ
攻撃者
クライアント
認可サーバ
復号化キーがなければ、
中身の読み取りまではできない。
傍受
ブロック
改ざん

16
4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができ
る。
正当なユーザ
攻撃者
クライアント
認可サーバ
ブラウザの
履歴の入手
認可サーバや
手前のリバプロのログの入手
認可リクエストや
認可レスポンスを読み取る

17
5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。
クライアント管理者
攻撃者
クライアント
認可サーバ
エンドポイント
変更の通知
攻撃者のサーバ
正規のトークン
リクエスト
誘導された
トークン
リクエストを取得
クライアント設定の変更

18
6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレ
スポンスを改ざんすることができる。
正当なユーザ
攻撃者
クライアント
認可サーバ
リバプロ
APIリクエスト
APIリクエスト
盗聴・改ざん TLS
終端

19
正当なユーザ
攻撃者
クライアント
認可サーバ
攻撃者配下の
認可サーバ
7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加
し、認可サーバからトークンを取得することができる。
メール等で
誘導
実際の
やり取り
トークンを取得
正当な
やり取り
正当な
やり取り
正当なユーザが
想定したやり取り

20
FAPIに準拠することで防げる攻撃8選
攻撃者の目的
1. 認可レスポンス横取り攻撃
2. 認可コード横取り攻撃
3. アクセストークン横取り攻撃
4. リダイレクトURI改ざん攻撃
5. トークンエンドポイントなりすまし攻撃
6. IdP mix-up攻撃
7. 認可レスポンス挿入攻撃
8. 認可コード挿入攻撃

21
攻撃者の目的
6. IdP mix-up攻撃

22
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
正当なユーザの認可レスポンスを盗聴して自身のブラウザからクライアントに流し込めれば、正当なユー
ザとしてクライアントにログインできる。
正当なユーザ攻撃者クライアント認可サーバ
アクセス
認証
盗聴
正当なユーザ
としてログイン
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: client.example.org
GET /cb?
HTTP/1.1
※そのまま送る。
POST /token HTTP/1.1
Host: server.example.com
Content-Type:
application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=
https://client.example.org/cb
&client_id=s6BhdRkqt3
GET /authorize?
response_type=code
&redirect_uri=
&scope=openid profile email
HTTP/1.1

23
1. 認可レスポンス横取り攻撃 ← stateを使った対抗策
stateを使って認可リクエストと認可レスポンスをバインドする。
正当なユーザクライアント認可サーバ
アクセス
認証
GET /authorize?
response_type=code
&redirect_uri=
&state=af0ifjsldkj HTTP/1.1
セッションに
stateを保存
認可レスポンスに
同一のstateを付与
セッションのstateと
認可レスポンスの
stateを比較検証
GET /cb?

24
stateを使って認可リクエストと認可レスポンスをバインドする。攻撃者から送られてきた認可レスポン
スには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検知でき
る。
アクセス
認証
セッションに
stateを保存
盗聴
GET /cb?
認可レスポンスに
同一のstateを付与
GET /cb?
GET /authorize?
response_type=code
&redirect_uri=
認可レスポンスと
同一のstateが
セッションに無い
ことを検知

25
事前に認可リクエストをトリガーし、stateを払い出しておく。正当なユーザの認可コードのみを盗聴し
て攻撃者用の認可レスポンスを作成し、自身のブラウザからクライアントに流し込めれば、正当なユーザ
としてクライアントにログインできる。
アクセス
認証
盗聴
正当なユーザ
としてログイン
Content-Type:
&redirect_uri=
アクセス
GET /cb?
&state=bk8kejboqlk HTTP/1.1
※stateは自身のものを流用。
GET /cb?
GET /authorize?
response_type=code
&redirect_uri=
GET /authorize?
response_type=code
…

26
2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth
2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。
アクセス
認証
GET /authorize?
response_type=code
&response_mode=jwt
&redirect_uri=
Host: server.example.com 署名を検証
GET /cb?
response=eyJr… HTTP/1.1
<JARMレスポンス>
{
"aud": "s6BhdRkqt3",
"code": "Splx…",
"iss": "https://server.example.com/",
"state": "af0ifjsldkj",
"exp": 1594141090
}
※署名あり。

27
2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth
2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可
レスポンスの改ざんを検知できる。
アクセス
認証
盗聴
アクセス
GET /cb?
※stateを自身のものを変えたとする。
GET /authorize?
response_type=code
&response_mode=jwt
&redirect_uri=
GET /cb?
{
"code": "Splx…",
"exp": 1594141090
}
※署名あり。
署名の検証で
改ざんを検知
GET /authorize?
response_type=code
…

28
2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン
OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー
ドとstateのハッシュ値を含める。
アクセス
認証
GET /authorize?
response_type=code id_token
&redirect_uri=
署名とハッシュ値
を検証
GET /cb#
&state=af0ifjsldkj
&id_token=eyJr… HTTP/1.1
<IDトークン>
{
"sub": "1001",
"c_hash": "QR2z…",
"s_hash": "9s6C…",
"auth_time": 1594140090,
"exp": 1594140390,
"iat": 1594140090
}
※署名あり。

29
2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン
OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー
ドとstateのハッシュ値を含める。IDトークンの署名とそれらハッシュ値を検証することで、クライアン
トは認可レスポンスの改ざんを検知できる。
アクセス
認証
盗聴
アクセス
GET /cb#
&state=bk8kejboqlk
※stateを自身のものに変えたとする。
署名とハッシュ値の
検証で改ざんを
検知
GET /authorize?
…
GET /cb#
&state=af0ifjsldkj
<IDトークン>
{
"sub": "1001",
"c_hash": "QR2z…",
"s_hash": "9s6C…",
"auth_time": 1594140090,
"exp": 1594140390,
"iat": 1594140090
}
※署名あり。
GET /authorize?
&redirect_uri=

30
攻撃者の目的
6. IdP mix-up攻撃

31
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
TLS終端するリソースサーバの手前のリバプロのログからAPIリクエスト(アクセストークン含む)を盗聴
できれば、正当なユーザのリソースにアクセスできるアクセストークンを取得できる。
認可サーバ
攻撃者
APIリクエスト
盗聴
APIリクエス
ト
アクセストークン
の取得
GET /resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer eyJr…
※そのまま送る
クライアントリバプロ

32
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド
(RFC 8705)
クライアント証明書をアクセストークンにバインドする。
アクセス
認証
Content-Type:
&redirect_uri=
クライアント証明書
を相互TLSで提示
APIリクエストクライアント証明書の
ハッシュ値を比較検証
アクセストークンに
のハッシュ値を
バインドする
を相互TLSで提示

33
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド
(RFC 8705)
クライアント証明書をアクセストークンにバインドする。たとえアクセストークンを取得しても攻撃者は
クライアント証明書の秘密鍵は取得できず、その所持をリソースサーバに示すことができないため、保護
リソースを取得できなくなる。
認可サーバ
攻撃者
アクセス
盗聴
APIリクエス
ト
の取得
※そのまま送る
クライアントリバプロ
正当なユーザ
APIリクエスト
認証
クライアント証明書を提示しない/
クライアント証明書が一致しない
不正なリクエストを検知
クライアント証明書の秘密鍵は
提示されないので奪えない

34
リダイレクトURIを改ざんした認可リクエストを正当なユーザに送り付け、攻撃者のサイトで認可コード
を盗聴して自身で
認可サーバに送ることができれば、正当なユーザのリソースにアクセスできるアクセストークンを取得で
きる。
正当なユーザリソースサーバ
認可サーバ攻撃者のサイト
攻撃者
リンクの送付
認証
傍受
APIリクエスト
の取得
GET /authorize?
response_type=code
&redirect_uri=
https://attacker.example.org/cb
HTTP/1.1
GET /cb?
HTTP/1.1
Host: attacker.example.org
Content-Type:
&redirect_uri=

35
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック
事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの
完全一致を検証する。
アクセス
認証
GET /authorize?
response_type=code
&redirect_uri=
HTTP/1.1
事前に登録された
リダイレクトURIと
認可リクエストの
リダイレクトURIを
比較検証
事前にリダイレクトURIを
完全URIで登録

36
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック
事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの
完全一致を検証する。
攻撃者が送り付けた認可リクエストはリダイレクトURIが一致しないため、認可サーバは攻撃を検知でき
る。
攻撃者
リンクの送付
GET /authorize?
response_type=code
&redirect_uri=
HTTP/1.1
リダイレクトURIの完全一致の
検証でリダイレクトURIの不正
を検知

37
4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート
トークンエンドポイントでのクライアント認証を強制する。
アクセス
認証
Content-Type:
&redirect_uri=
&client_secret=jngso0033i
クライアント認証を強制し
クライアントクレデンシャル
を比較検証

38
4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート
トークンエンドポイントでのクライアント認証を強制する。アクセストークンの入手にはクライアントク
レデンシャルの取得も必要になり、盗聴した認可コードだけではアクセストークンを取得できなくなる。
攻撃者
リンクの送付
認証
傍受
GET /authorize?
response_type=code
&redirect_uri=
HTTP/1.1
GET /cb?
HTTP/1.1
クライアントクレデンシャルを
提示しない不正なリクエストを
検知
Content-Type:
&redirect_uri=

39
トークンエンドポイントの変更通知をクライアント管理者に送り付けてエンドポイントの設定を変更させ、
攻撃者のサイトでトークンリクエストを取得できれば、認可コードもクライアントクレデンシャルも取得
でき、それらでアクセストークンを取得できる。
認可サーバ攻撃者のサーバ
攻撃者
変更通知
アクセス
認証
傍受
APIリクエスト
の取得
Content-Type:
&redirect_uri=
&client_secret=jngso0033i
クライアント管理者クライアント
変更
認可コードもクライアント
クレデンシャルも取得できる

40
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認
証 (RFC 8705)
クライアント証明書をクライアント認証に用いる。
アクセス
認証
Content-Type:
&redirect_uri=
クライアント証明書を使った
クライアント認証を強制し
クライアント証明書を比較検証

41
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認
証 (RFC 8705)
クライアント証明書をクライアント認証に用いる。トークンリクエストを取得しても攻撃者はクライアン
ト証明書の秘密鍵は取得できず、その所持を認可サーバに示すことができないため、クライアント認証に
失敗しアクセストークンを取得できなくなる。
認可サーバ攻撃者のサーバ
攻撃者
変更通知
アクセス
認証
傍受
Content-Type:
&redirect_uri=
クライアント管理者クライアント
変更
クライアント証明書の秘密鍵は
提示されないので奪えない
クライアント証明書を提示しない
不正なリクエストを検知

42
自身に対する
認可リクエストをトリガ
6. IdP mix-up攻撃
認可サーバを準備し、正当なクライアントの認可サーバとして、かつ正当な認可サーバのクライアントと
して登録する。
正当なユーザを攻撃者配下の認可サーバに誘導することで、アクセストークンを取得できる。
認可サーバ
攻撃者
アクセスを誘導
認証
傍受
APIリクエスト
の取得
クライアント
正当なクライアントの認可サーバ
として登録されている
攻撃者配下の
認可サーバ
正当な認可サーバのクライアント
として登録されている
Content-Type:
&redirect_uri=
&client_id=o3ksnRuew2
GET /cb?
code=SplxlOBeZQQYbY…
GET /authorize?
response_type=code
&redirect_uri=

43
6. IdP mix-up攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。JWT内のissクレームとaudクレームを検証す
ることで、クライアントは認可レスポンスの不正を検知できる。
自身に対する
認可リクエストをトリガ
認可サーバ
攻撃者
アクセスを誘導
認証
クライアント攻撃者配下の
認可サーバ
GET /cb?
GET /authorize?
response_type=code
&response_mode=jwt
…
HTTP/1.1
Host: attacker.example.com
{
"aud": "o3ksnRuew2",
…
}
※署名あり。
issクレームとaudクレームの検証で
意図した認可サーバからのレスポンスではないことや
自身宛てのレスポンスではないことを検知

44
攻撃者の目的
6. IdP mix-up攻撃

45
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
攻撃者の認可レスポンスを正当なユーザに送り付け、正当なユーザのブラウザからクライアントに流し込
ませることができれば、攻撃者としてクライアントにログインさせることができる。
アクセス
認証
送信
攻撃者として
ログイン
GET /cb?
HTTP/1.1
GET /cb?
HTTP/1.1
Content-Type:
&redirect_uri=
GET /authorize?
response_type=code
&redirect_uri=
HTTP/1.1

46
7. 認可レスポンス挿入攻撃 ← stateを使った対抗策
stateを使って認可リクエストと認可レスポンスをバインドする。正当なユーザから送られてきた認可レ
スポンスには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検
知できる。
アクセス
認証
送信
GET /cb?
GET /cb?
GET /authorize?
response_type=code
&redirect_uri=
認可レスポンスと
同一のstateが
セッションに無い
ことを検知

47
事前に正当なユーザの認可リクエストを盗聴し、stateを取得しておく。攻撃者の認可コードのみを使っ
て正当なユーザ用の認可レスポンスを作成し、クライアントに流し込ませることができれば、攻撃者とし
てクライアントにログインさせることができる。
アクセス
認証
送信
攻撃者として
ログイン
Content-Type:
&redirect_uri=
アクセス
GET /cb?
※stateは正当なユーザのものを流用。
GET /cb?
GET /authorize?
response_type=code
&redirect_uri=
GET /authorize?
response_type=code
…
盗聴

48
8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests)
認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに
登録する。
アクセス
認証
PARリクエスト
PARレスポンス
POST /par HTTP/1.1
Content-Type:
client_assertion_type=
urn:ietf:params:oauth:client-
assertion-type:jwt-bearer
&client_assertion=eyJr…
&request=eyJr…
<リクエストオブジェクト>
{
"aud": "https://server.example.com/",
"nbf": 1594140030,
"scope": "openid profile email",
"iss": "s6BhdRkqt3",
"response_type": "code id_token",
"redirect_uri":
"https://client.example.org/cb",
"exp": 1594140390,
"client_id": "s6BhdRkqt3“,
"code_challenge": "K2-l…",
"code_challenge_method": "S256"
}
※署名あり。
GET /authorize?
client_id=s6BhdRkqt3
&request_uri=
urn:ietf:params:oauth:
request_uri:6esc…
HTTP/1.1
HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control:
no-cache, no-store
{
"request_uri":
"urn:ietf:params:oauth:
request_uri:6esc…",
"expires_in": 60
}
事前にパラメータを
JWTにまとめて送信
認可リクエストに
パラメータは直接
含まれない

49
8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests)
認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに
登録する。認可
リクエストにはリクエストオブジェクトへの参照URIしか含まれないため、stateを取得できなくなる。
アクセス
GET /authorize?
client_id=s6BhdRkqt3
&request_uri=
urn:ietf:params:oauth:
request_uri:6esc…
HTTP/1.1
盗聴
PARリクエスト
PARレスポンス
POST /par HTTP/1.1
Content-Type:
client_assertion_type=
urn:ietf:params:oauth:client-
assertion-type:jwt-bearer
&client_assertion=eyJr…
&request=eyJr…
<リクエストオブジェクト>
{
"aud": "https://server.example.com/",
"nbf": 1594140030,
"scope": "openid profile email",
"iss": "s6BhdRkqt3",
"response_type": "code id_token",
"redirect_uri":
"https://client.example.org/cb",
"exp": 1594140390,
"client_id": "s6BhdRkqt3“,
"code_challenge": "K2-l…",
"code_challenge_method": "S256"
}
※署名あり。
stateを盗聴できないので
攻撃が成立しない
(正当なユーザ用の認可
レスポンスを作成できない)

50
8. 認可コード挿入攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可
レスポンスの改ざんを検知できる。
アクセス
認証
送信
アクセス
GET /cb?
※stateを正当なユーザのものに
変えたとする。
GET /authorize?
response_type=code
&response_mode=jwt
&redirect_uri=
GET /authorize?
response_type=code
…
盗聴
GET /cb?
{
"code": "Splx…",
"exp": 1594141090
}
※署名あり。
署名の検証で
改ざんを検知

51
FAPIに準拠することで防げる攻撃8選 ~ まとめ ~
• stateを使った対抗策
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
• 分離署名としてのIDトークン
• アクセストークンへのクライアント証明書のバインド (RFC 8705)
• リダイレクトURIの完全一致チェック
• パブリッククライアントの非サポート
• クライアント証明書を使ったクライアント認証 (RFC 8705)
6. IdP mix-up攻撃
• PAR (OAuth 2.0 Pushed Authorization Requests)

Contents
52
1. FAPIとは

53
主な特徴
 OAuth 2.0/OpenID ConnectやSAMLに対応
 LDAPサーバやActive Directoryと連携可能
 GitHubなどのユーザアカウントを利用した
ソーシャルログインにも対応
Keycloakとは
• Keycloakは、Red Hat社を中心に開発されている
IAM (Identity and Access Management: IDアクセス管理)のOSS。
• シングルサインオンや、OAuth 2.0の認可サーバの機能を提供。
主要標準に対応したID連携
(OAuth 2.0の認可サーバーを含む)
Keycloak
LDAP
Active
Directory
RDB
OpenID Connect SAML
GitHub
Twitter Facebook
ID管理と認証
ソーシャルログイン
(Identity Brokering)

54
Keycloakの強み
• 最先端の標準仕様にいち早く追従していく、コミュニティ力！
• Keycloakメンテナの乗松さん(日立)が、FAPI-SIG (Financial-grade API Security :
Special Interest Group)を立ち上げ、活動をリードしています。
標準仕様 Keycloakのサポート
日
OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Flow - Core 1.0 2021/5
Financial-grade API (FAPI) Security Profile 1.0 - Part 1: Baseline 2021/6
Financial-grade API (FAPI) Security Profile 1.0 - Part 2: Advanced 2021/6
Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)
2021/7
Financial-grade API: Client Initiated Backchannel Authentication Profile (FAPI-CIBA) 2021/7
RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) 2021/7
Open Finance Brasil Financial-grade API Security Profile 1.0 2021/7
FAPI 2.0 Baseline Profile 絶賛作業中！
Grant Management for OAuth 2.0 絶賛作業中！
OAuth 2.0 Rich Authorization Requests (RAR) 絶賛作業中！
OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) 絶賛作業中！

55
FAPIに準拠する際の一般的な課題
FAPIに準拠することで防げる攻撃
• 分離署名としてのIDトークン
• アクセストークンへのクライアント証明書のバインド (RFC 8705)
• リダイレクトURIの完全一致チェック
• パブリッククライアントの非サポート
• クライアント証明書を使ったクライアント認証 (RFC 8705)
6. IdP mix-up攻撃
• PAR (OAuth 2.0 Pushed Authorization Requests)
• 設定項目が多すぎる。。。・・・今回ご紹介した以下のような対抗策を適切に設定する必要がある。
• 適切に設定されているか、つまりFAPIに準拠した状態になっているか、設定ミスによってセ
キュリティホールが生じていないかを確認するのも大変。

56
• クライアントポリシーという機構を使います。
特定の条件(コンディション)に合致するクライアントに、FAPIのようなセキュリティプロファイルを適用することができま
す。
セキュリティプロファイル
コンディション
KeycloakではFAPIをどのように設定するか
myroleというロールを持つ
myscopeというスコープを持つ
FAPI 1.0 - Part 1 Baseline
FAPI 1.0 - Part 2 Advanced
FAPI-CIBA
例えば以下のようなことをクライアントポリシーで設定できます。
に合致する
クライアントに
を適用する。
などなど
• これによって何がうれしいか
• 対象のクライアントを自動的にFAPIに準拠させてくれる！ ← 細かな設定が不要に！
• クライアントと紐づいたKeycloakへのリクエストがFAPIに準拠しているかどうかを
チェックしてくれる。
• クライアントの設定がFAPIに準拠しているかをチェックしてくれる。

57
myroleというロールを持つ FAPI 1.0 - Part 2 Advanced
例えば以下のようなクライアントポリシーを作成した場合:
に合致する
を適用する。
GET /realms/myrealm/protocol/openid-connect/auth?
client_id=myclient
&response_type=code
&scope=openid
&state=kci63sqvvwd
&nonce=c93vbo8v8ead
&redirect_uri=https://localhost:8082/callback HTTP/1.1
Host: localhost:8443
ログイン画面が表示されるエラーが返される
HTTP/1.1 302 Found
Location: https://localhost:8082/callback?
error=invalid_request
&error_description=
Missing parameter: ‘request’ or ‘request_uri’
&state=kci63sqvvwd
リクエストオブジェクトがないという意
以下のようなリクエスト(FAPIに非準拠)を送ると・・・
myroleロールを持たないクライアントの場合: myroleロールを持つクライアントの場合:
myroleロールを付けると
myroleロールを取ると

58
myroleというロールを持つ FAPI 1.0 - Part 2 Advanced
例えば以下のようなクライアントポリシーを作成した場合:
に合致する
を適用する。
GET /realms/myrealm/protocol/openid-connect/auth?
client_id=myclient
&response_type=code id_token
&scope=openid
&request=eyJraWQiOiI2R2l… HTTP/1.1
Host: localhost:8443
ログイン画面が表示される
もちろんFAPIに準拠したリクエストを送ると・・・
myroleロールを持つクライアントでも

59
ちなみに、FAPIに準拠したリクエストを送るのがハードルが高いという方は・・・
日立からOIDFのCertificationをパスしたFAPIのクライアント実装を公開していますので是非ご活用ください！
参考: https://openid.net/developers/certified/#FAPIRP

60
まとめ
- FAPIの概要のご説明
 OAuth 2.0やOIDCをベースにした、高いレベルのセキュリティを必要とするあら
ゆる市場領域のAPIに適用できる仕様です。
- FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介
2. 認可コード横取り攻撃 ← JARM、分離署名としてのIDトークン
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書の
バインド
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック、パブ
リッククライアントの
非サポート
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクラ
イアント認証
6. IdP mix-up攻撃 ← JARM、分離署名としてのIDトークン
7. 認可レスポンス挿入攻撃 ← stateを使った対抗策
8. 認可コード挿入攻撃 ← PAR、JARM、分離署名としてのIDトークン
- KeycloakにおけるFAPI対応のご紹介

61
Trademarks
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.
• Twitterは、Twitter,Inc.の登録商標です。
• Facebookは、Facebook,Inc.の登録商標です。
• Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.

KeycloakでFAPIに対応した高セキュリティなAPIを公開する

KeycloakでFAPIに対応した高セキュリティなAPIを公開する

More Related Content

What's hot

Similar to KeycloakでFAPIに対応した高セキュリティなAPIを公開する

More from Hitachi, Ltd. OSS Solution Center.

KeycloakでFAPIに対応した高セキュリティなAPIを公開する