SlideShare a Scribd company logo
1 of 63
Download to read offline
© Hitachi, Ltd. 2022. All rights reserved.
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
CloudNative Days Tokyo 2022
株式会社 日立製作所
田畑 義之
1
© Hitachi, Ltd. 2022. All rights reserved.
自己紹介
田畑 義之 (たばた よしゆき)
 株式会社 日立製作所 アーキテクチャセンタ
 ソフトウェアエンジニア
 GitHub: @y-tabata
• 認証認可やAPI関連分野のソリューション開発&コンサルティング
 金融、公共、社会、産業分野における
API管理基盤や認証認可システムの導入支援
• 認証認可・API管理関連のOSSへのコントリビュート
 Keycloak (IAMのOSS)
 3scale (API管理のOSS)
• 情報発信
 Keycloak書籍
 ThinkIT/@ITでのWeb記事連載
 Apidays/OAuth Security Workshop/CloudNative Daysなど、国内外のイベントでの登壇
2
© Hitachi, Ltd. 2022. All rights reserved.
セッション概要
• FAPI (Financial-grade API)という高セキュリティなAPIを公開するための仕様があります。
• システムのセキュリティは高ければ高いほど望ましいですが、実案件では対応コストやユー
ザビリティとの
トレードオフを見ていかないといけません。
 一方で、FAPIに準拠しないにしても、どんな攻撃のリスクがあるかを知り、自システムで
はどうやって対策
できるかを考えておくことは大切です。
低い対応コスト/
高いユーザビリティ
高いセキュリティレベル
• FAPIの概要のご説明
• FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介
• IAMを実現するOSSであるKeycloakにおけるFAPI対応のご紹介
本セッションでは・・・
© Hitachi, Ltd. 2022. All rights reserved.
Contents
3
1. FAPIとは
2. FAPIに準拠することで防げる攻撃 ~8選~
3. KeycloakにおけるFAPI対応
© Hitachi, Ltd. 2022. All rights reserved.
Contents
4
1. FAPIとは
2. FAPIに準拠することで防げる攻撃 ~8選~
3. KeycloakにおけるFAPI対応
5
© Hitachi, Ltd. 2022. All rights reserved.
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)
© Hitachi, Ltd. 2022. All rights reserved.
Contents
6
1. FAPIとは
2. FAPIに準拠することで防げる攻撃 ~8選~
3. KeycloakにおけるFAPI対応
7
© Hitachi, Ltd. 2022. All rights reserved.
前提
• OAuth 2.0/OIDCで最も推奨される認可コードフローを前提とします(ハイブリッドフロー
を含む)。
※インプリシットフローやリソースオーナパスワードクレデンシャルズフローだと、説明すべき攻撃方法の数が多くなってしまうため。
正当なユーザ クライアント リソースサーバ
認可サーバ
アクセス
認可リクエスト
ログイン画面
ログイン
認可レスポンス
トークンリクエスト
トークンレスポンス
APIリクエスト
APIレスポンス
画面表示
8
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~
1. 正当なユーザとしてクライアントにログインすること。
2. 正当なユーザのリソースにアクセスすること。
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
※参考: FAPI 2.0 Attacker Model
https://openid.net/specs/fapi-2_0-attacker-model-00.html
9
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~
1. 正当なユーザとしてクライアントにログインすること。
2. 正当なユーザのリソースにアクセスすること。
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
正当なユーザ
攻撃者
クライアント
正当なユーザ
正当なユーザとしてログインすることで以下のようなことができる。
• クライアントに設定している情報からの、正当なユーザの個人情報の取得
→住所や電話番号、プライベートな写真の取得など。
• 正当なユーザの周辺のユーザへの攻撃
→「友達」として登録されているユーザへのプリペイドカード番号の要求など。
10
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~
1. 正当なユーザとしてクライアントにログインすること。
2. 正当なユーザのリソースにアクセスすること。
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
正当なユーザ
攻撃者
クライアント 正当なユーザ
リソースサーバ
正当なユーザのリソースにアクセスすることで以下のようなことができる。
• リソースサーバに保存している情報からの、正当なユーザの個人情報の取得
→保存しているドキュメントや写真、動画の取得など。
• 金融取引をトリガーするために利用できるAPIのコール
→正当なユーザの口座から攻撃者の口座への送金のリクエストなど。
11
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~
1. 正当なユーザとしてクライアントにログインすること。
2. 正当なユーザのリソースにアクセスすること。
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
正当なユーザ
攻撃者
クライアント
リソースサーバ
攻撃者
攻撃者
正当なユーザに攻撃者としてログインさせたり、攻撃者のリソースにアクセスさせることで以下のようなことができる。
• 攻撃者アカウントへ登録された正当なユーザの情報の取得
→正当なユーザが誤って攻撃者のアカウントへ登録してしまった個人情報や口座情報の取得など。
• 正当なユーザのアカウント情報を用いた他システムへのログイン
→正当なユーザが誤って攻撃者のアカウントへ紐づけてしまった他システムのアカウントを用いたログインなど。
12
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
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
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
自作メッセージを
送付
改ざんした
メッセージを送付
正当なメッセージを
送付
14
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
2. 正当なユーザにリンクを送付して、そこに訪問させることができる。
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
攻撃者のサイト
リンクを
送付
訪問
15
© Hitachi, Ltd. 2022. All rights reserved.
不正なWiFiアクセスポイントや
侵害したネットワーク内
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
復号化キーがなければ、
中身の読み取りまではできない。
傍受
ブロック
改ざん
16
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができ
る。
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
ブラウザの
履歴の入手
認可サーバや
手前のリバプロのログの入手
認可リクエストや
認可レスポンスを読み取る
認可リクエスト
17
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。
クライアント管理者
攻撃者
クライアント
リソースサーバ
認可サーバ
エンドポイント
変更の通知
攻撃者のサーバ
正規のトークン
リクエスト
誘導された
トークンリクエスト
トークン
リクエストを取得
クライアント設定の変更
18
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレ
スポンスを改ざんすることができる。
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
リバプロ
APIリクエスト
APIリクエスト
盗聴・改ざん TLS
終端
19
© Hitachi, Ltd. 2022. All rights reserved.
まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~
正当なユーザ
攻撃者
クライアント
リソースサーバ
認可サーバ
攻撃者配下の
認可サーバ
7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加
し、認可サーバからトークンを取得することができる。
メール等で
誘導
実際の
やり取り
トークンを取得
正当な
やり取り
正当な
やり取り
正当なユーザが
想定したやり取り
20
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的
1. 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃
2. 認可コード横取り攻撃
2. 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃
4. リダイレクトURI改ざん攻撃
5. トークンエンドポイントなりすまし攻撃
6. IdP mix-up攻撃
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
7. 認可レスポンス挿入攻撃
8. 認可コード挿入攻撃
21
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的
1. 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃
2. 認可コード横取り攻撃
2. 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃
4. リダイレクトURI改ざん攻撃
5. トークンエンドポイントなりすまし攻撃
6. IdP mix-up攻撃
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
7. 認可レスポンス挿入攻撃
8. 認可コード挿入攻撃
22
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃
正当なユーザの認可レスポンスを盗聴して自身のブラウザからクライアントに流し込めれば、正当なユー
ザとしてクライアントにログインできる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
盗聴
認可レスポンス
トークンリクエスト
トークンレスポンス
正当なユーザ
としてログイン
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: client.example.org
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: client.example.org
※そのまま送る。
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
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
23
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃 ← stateを使った対抗策
stateを使って認可リクエストと認可レスポンスをバインドする。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
セッションに
stateを保存
認可レスポンスに
同一のstateを付与
セッションのstateと
認可レスポンスの
stateを比較検証
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
24
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃 ← stateを使った対抗策
stateを使って認可リクエストと認可レスポンスをバインドする。攻撃者から送られてきた認可レスポン
スには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検知でき
る。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
セッションに
stateを保存
盗聴
認可レスポンス
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
※そのまま送る。
認可レスポンスに
同一のstateを付与
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
認可レスポンスと
同一のstateが
セッションに無い
ことを検知
25
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
2. 認可コード横取り攻撃
事前に認可リクエストをトリガーし、stateを払い出しておく。正当なユーザの認可コードのみを盗聴し
て攻撃者用の認可レスポンスを作成し、自身のブラウザからクライアントに流し込めれば、正当なユーザ
としてクライアントにログインできる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
盗聴
認可レスポンス
トークンリクエスト
トークンレスポンス
正当なユーザ
としてログイン
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 /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=bk8kejboqlk HTTP/1.1
Host: client.example.org
※stateは自身のものを流用。
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
GET /authorize?
response_type=code
…
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
26
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth
2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
GET /authorize?
response_type=code
&response_mode=jwt
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com 署名を検証
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
<JARMレスポンス>
{
"aud": "s6BhdRkqt3",
"code": "Splx…",
"iss": "https://server.example.com/",
"state": "af0ifjsldkj",
"exp": 1594141090
}
※署名あり。
27
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth
2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可
レスポンスの改ざんを検知できる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
盗聴
認可レスポンス
アクセス
認可リクエスト
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
※stateを自身のものを変えたとする。
GET /authorize?
response_type=code
&response_mode=jwt
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
<JARMレスポンス>
{
"aud": "s6BhdRkqt3",
"code": "Splx…",
"iss": "https://server.example.com/",
"state": "af0ifjsldkj",
"exp": 1594141090
}
※署名あり。
署名の検証で
改ざんを検知
GET /authorize?
response_type=code
…
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
28
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン
OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー
ドとstateのハッシュ値を含める。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
GET /authorize?
response_type=code id_token
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
署名とハッシュ値
を検証
GET /cb#
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
&id_token=eyJr… HTTP/1.1
Host: client.example.org
<IDトークン>
{
"sub": "1001",
"aud": "s6BhdRkqt3",
"c_hash": "QR2z…",
"s_hash": "9s6C…",
"auth_time": 1594140090,
"iss": "https://server.example.com/",
"exp": 1594140390,
"iat": 1594140090
}
※署名あり。
29
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン
OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー
ドとstateのハッシュ値を含める。IDトークンの署名とそれらハッシュ値を検証することで、クライアン
トは認可レスポンスの改ざんを検知できる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
盗聴
認可レスポンス
アクセス
認可リクエスト
GET /cb#
code=SplxlOBeZQQYbYS6WxSbIA
&state=bk8kejboqlk
&id_token=eyJr… HTTP/1.1
Host: client.example.org
※stateを自身のものに変えたとする。
署名とハッシュ値の
検証で改ざんを
検知
GET /authorize?
response_type=code id_token
…
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
GET /cb#
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
&id_token=eyJr… HTTP/1.1
Host: client.example.org
<IDトークン>
{
"sub": "1001",
"aud": "s6BhdRkqt3",
"c_hash": "QR2z…",
"s_hash": "9s6C…",
"auth_time": 1594140090,
"iss": "https://server.example.com/",
"exp": 1594140390,
"iat": 1594140090
}
※署名あり。
GET /authorize?
response_type=code id_token
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
30
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的
1. 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃
2. 認可コード横取り攻撃
2. 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃
4. リダイレクトURI改ざん攻撃
5. トークンエンドポイントなりすまし攻撃
6. IdP mix-up攻撃
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
7. 認可レスポンス挿入攻撃
8. 認可コード挿入攻撃
31
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃
TLS終端するリソースサーバの手前のリバプロのログからAPIリクエスト(アクセストークン含む)を盗聴
できれば、正当なユーザのリソースにアクセスできるアクセストークンを取得できる。
リソースサーバ
認可サーバ
攻撃者
APIリクエスト
盗聴
APIリクエス
ト
アクセストークン
の取得
GET /resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer eyJr…
※そのまま送る
GET /resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer eyJr…
クライアント リバプロ
32
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド
(RFC 8705)
クライアント証明書をアクセストークンにバインドする。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
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
クライアント証明書
を相互TLSで提示
リソースサーバ
APIリクエスト クライアント証明書の
ハッシュ値を比較検証
アクセストークンに
クライアント証明書
のハッシュ値を
バインドする
クライアント証明書
を相互TLSで提示
33
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド
(RFC 8705)
クライアント証明書をアクセストークンにバインドする。たとえアクセストークンを取得しても攻撃者は
クライアント証明書の秘密鍵は取得できず、その所持をリソースサーバに示すことができないため、保護
リソースを取得できなくなる。
リソースサーバ
認可サーバ
攻撃者
アクセス
盗聴
APIリクエス
ト
アクセストークン
の取得
GET /resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer eyJr…
※そのまま送る
GET /resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer eyJr…
クライアント リバプロ
正当なユーザ
APIリクエスト
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
クライアント証明書を提示しない/
クライアント証明書が一致しない
不正なリクエストを検知
クライアント証明書の秘密鍵は
提示されないので奪えない
34
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
4. リダイレクトURI改ざん攻撃
リダイレクトURIを改ざんした認可リクエストを正当なユーザに送り付け、攻撃者のサイトで認可コード
を盗聴して自身で
認可サーバに送ることができれば、正当なユーザのリソースにアクセスできるアクセストークンを取得で
きる。
正当なユーザ リソースサーバ
認可サーバ 攻撃者のサイト
攻撃者
リンクの送付
認可リクエスト
認証
認可レスポンス
傍受
トークンリクエスト
トークンレスポンス
APIリクエスト
アクセストークン
の取得
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://attacker.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: attacker.example.org
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://attacker.example.org/cb
&client_id=s6BhdRkqt3
35
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック
事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの
完全一致を検証する。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
事前に登録された
リダイレクトURIと
認可リクエストの
リダイレクトURIを
比較検証
事前にリダイレクトURIを
完全URIで登録
36
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック
事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの
完全一致を検証する。
攻撃者が送り付けた認可リクエストはリダイレクトURIが一致しないため、認可サーバは攻撃を検知でき
る。
正当なユーザ リソースサーバ
認可サーバ 攻撃者のサイト
攻撃者
リンクの送付
認可リクエスト
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://attacker.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
リダイレクトURIの完全一致の
検証でリダイレクトURIの不正
を検知
37
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート
トークンエンドポイントでのクライアント認証を強制する。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
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
&client_secret=jngso0033i
クライアント認証を強制し
クライアントクレデンシャル
を比較検証
38
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート
トークンエンドポイントでのクライアント認証を強制する。アクセストークンの入手にはクライアントク
レデンシャルの取得も必要になり、盗聴した認可コードだけではアクセストークンを取得できなくなる。
正当なユーザ リソースサーバ
認可サーバ 攻撃者のサイト
攻撃者
リンクの送付
認可リクエスト
認証
認可レスポンス
傍受
トークンリクエスト
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://attacker.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: attacker.example.org
クライアントクレデンシャルを
提示しない不正なリクエストを
検知
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://attacker.example.org/cb
&client_id=s6BhdRkqt3
39
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
5. トークンエンドポイントなりすまし攻撃
トークンエンドポイントの変更通知をクライアント管理者に送り付けてエンドポイントの設定を変更させ、
攻撃者のサイトでトークンリクエストを取得できれば、認可コードもクライアントクレデンシャルも取得
でき、それらでアクセストークンを取得できる。
正当なユーザ リソースサーバ
認可サーバ 攻撃者のサーバ
攻撃者
エンドポイント
変更通知
アクセス
認証
認可レスポンス
傍受
トークンリクエスト
トークンレスポンス
APIリクエスト
アクセストークン
の取得
POST /token HTTP/1.1
Host: attacker.example.org
Content-Type:
application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=
https://attacker.example.org/cb
&client_id=s6BhdRkqt3
&client_secret=jngso0033i
クライアント管理者クライアント
エンドポイント
変更
認可リクエスト
トークンリクエスト
認可コードもクライアント
クレデンシャルも取得できる
40
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認
証 (RFC 8705)
クライアント証明書をクライアント認証に用いる。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
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
クライアント証明書を使った
クライアント認証を強制し
クライアント証明書を比較検証
41
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認
証 (RFC 8705)
クライアント証明書をクライアント認証に用いる。トークンリクエストを取得しても攻撃者はクライアン
ト証明書の秘密鍵は取得できず、その所持を認可サーバに示すことができないため、クライアント認証に
失敗しアクセストークンを取得できなくなる。
正当なユーザ リソースサーバ
認可サーバ 攻撃者のサーバ
攻撃者
エンドポイント
変更通知
アクセス
認証
認可レスポンス
傍受
トークンリクエスト
POST /token HTTP/1.1
Host: attacker.example.org
Content-Type:
application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=
https://attacker.example.org/cb
&client_id=s6BhdRkqt3
クライアント管理者クライアント
エンドポイント
変更
認可リクエスト
トークンリクエスト
クライアント証明書の秘密鍵は
提示されないので奪えない
クライアント証明書を提示しない
不正なリクエストを検知
42
© Hitachi, Ltd. 2022. All rights reserved.
認可リクエスト
自身に対する
認可リクエストをトリガ
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
6. IdP mix-up攻撃
認可サーバを準備し、正当なクライアントの認可サーバとして、かつ正当な認可サーバのクライアントと
して登録する。
正当なユーザを攻撃者配下の認可サーバに誘導することで、アクセストークンを取得できる。
正当なユーザ リソースサーバ
認可サーバ
攻撃者
アクセスを誘導
認証
認可レスポンス
傍受
APIリクエスト
アクセストークン
の取得
クライアント
トークンリクエスト
正当なクライアントの認可サーバ
として登録されている
攻撃者配下の
認可サーバ
認可リクエスト
トークンリクエスト
トークンレスポンス
正当な認可サーバのクライアント
として登録されている
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=o3ksnRuew2
GET /cb?
code=SplxlOBeZQQYbY…
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
GET /authorize?
response_type=code
&client_id=o3ksnRuew2
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
43
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザのリソースにアクセスすること。
6. IdP mix-up攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。JWT内のissクレームとaudクレームを検証す
ることで、クライアントは認可レスポンスの不正を検知できる。
認可リクエスト
自身に対する
認可リクエストをトリガ
正当なユーザ リソースサーバ
認可サーバ
攻撃者
アクセスを誘導
認証
認可レスポンス
クライアント 攻撃者配下の
認可サーバ
認可リクエスト
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
GET /authorize?
response_type=code
&response_mode=jwt
&client_id=o3ksnRuew2
…
HTTP/1.1
Host: attacker.example.com
<JARMレスポンス>
{
"aud": "o3ksnRuew2",
"iss": "https://server.example.com/",
…
}
※署名あり。
issクレームとaudクレームの検証で
意図した認可サーバからのレスポンスではないことや
自身宛てのレスポンスではないことを検知
44
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的
1. 正当なユーザとしてクライアントにログインすること。
1. 認可レスポンス横取り攻撃
2. 認可コード横取り攻撃
2. 正当なユーザのリソースにアクセスすること。
3. アクセストークン横取り攻撃
4. リダイレクトURI改ざん攻撃
5. トークンエンドポイントなりすまし攻撃
6. IdP mix-up攻撃
3. 正当なユーザに攻撃者としてログインさせること。
4. 正当なユーザに攻撃者のリソースにアクセスさせること。
7. 認可レスポンス挿入攻撃
8. 認可コード挿入攻撃
45
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
7. 認可レスポンス挿入攻撃
攻撃者の認可レスポンスを正当なユーザに送り付け、正当なユーザのブラウザからクライアントに流し込
ませることができれば、攻撃者としてクライアントにログインさせることができる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
送信
認可レスポンス
トークンリクエスト
トークンレスポンス
攻撃者として
ログイン
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: client.example.org
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
HTTP/1.1
Host: client.example.org
※そのまま送る。
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
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
HTTP/1.1
Host: server.example.com
46
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザとしてクライアントにログインすること。
7. 認可レスポンス挿入攻撃 ← stateを使った対抗策
stateを使って認可リクエストと認可レスポンスをバインドする。正当なユーザから送られてきた認可レ
スポンスには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検
知できる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
送信
認可レスポンス
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=bk8kejboqlk HTTP/1.1
Host: client.example.org
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=bk8kejboqlk HTTP/1.1
Host: client.example.org
※そのまま送る。
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
認可レスポンスと
同一のstateが
セッションに無い
ことを検知
47
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
8. 認可コード挿入攻撃
事前に正当なユーザの認可リクエストを盗聴し、stateを取得しておく。攻撃者の認可コードのみを使っ
て正当なユーザ用の認可レスポンスを作成し、クライアントに流し込ませることができれば、攻撃者とし
てクライアントにログインさせることができる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
送信
認可レスポンス
トークンリクエスト
トークンレスポンス
攻撃者として
ログイン
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 /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj HTTP/1.1
Host: client.example.org
※stateは正当なユーザのものを流用。
GET /cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=bk8kejboqlk HTTP/1.1
Host: client.example.org
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
GET /authorize?
response_type=code
…
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
盗聴
48
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests)
認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに
登録する。
正当なユーザ クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
トークンリクエスト
トークンレスポンス
PARリクエスト
PARレスポンス
POST /par HTTP/1.1
Host: server.example.com
Content-Type:
application/x-www-form-urlencoded
client_assertion_type=
urn:ietf:params:oauth:client-
assertion-type:jwt-bearer
&client_assertion=eyJr…
&request=eyJr…
&client_id=s6BhdRkqt3
<リクエストオブジェクト>
{
"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",
"state": "af0ifjsldkj",
"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
Host: server.example.com
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
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
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
Host: server.example.com
盗聴
PARリクエスト
PARレスポンス
POST /par HTTP/1.1
Host: server.example.com
Content-Type:
application/x-www-form-urlencoded
client_assertion_type=
urn:ietf:params:oauth:client-
assertion-type:jwt-bearer
&client_assertion=eyJr…
&request=eyJr…
&client_id=s6BhdRkqt3
<リクエストオブジェクト>
{
"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",
"state": "af0ifjsldkj",
"exp": 1594140390,
"client_id": "s6BhdRkqt3“,
"code_challenge": "K2-l…",
"code_challenge_method": "S256"
}
※署名あり。
stateを盗聴できないので
攻撃が成立しない
(正当なユーザ用の認可
レスポンスを作成できない)
50
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選
攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。
8. 認可コード挿入攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可
レスポンスの改ざんを検知できる。
正当なユーザ 攻撃者 クライアント 認可サーバ
アクセス
認可リクエスト
認証
認可レスポンス
送信
認可レスポンス
アクセス
認可リクエスト
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
※stateを正当なユーザのものに
変えたとする。
GET /authorize?
response_type=code
&response_mode=jwt
&client_id=s6BhdRkqt3
&redirect_uri=
https://client.example.org/cb
&scope=openid profile email
&state=bk8kejboqlk HTTP/1.1
Host: server.example.com
GET /authorize?
response_type=code
…
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
盗聴
GET /cb?
response=eyJr… HTTP/1.1
Host: client.example.org
<JARMレスポンス>
{
"aud": "s6BhdRkqt3",
"code": "Splx…",
"iss": "https://server.example.com/",
"state": "af0ifjsldkj",
"exp": 1594141090
}
※署名あり。
署名の検証で
改ざんを検知
51
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠することで防げる攻撃8選 ~ まとめ ~
1. 認可レスポンス横取り攻撃
• stateを使った対抗策
2. 認可コード横取り攻撃
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
• 分離署名としてのIDトークン
3. アクセストークン横取り攻撃
• アクセストークンへのクライアント証明書のバインド (RFC 8705)
4. リダイレクトURI改ざん攻撃
• リダイレクトURIの完全一致チェック
• パブリッククライアントの非サポート
5. トークンエンドポイントなりすまし攻撃
• クライアント証明書を使ったクライアント認証 (RFC 8705)
6. IdP mix-up攻撃
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
7. 認可レスポンス挿入攻撃
• stateを使った対抗策
8. 認可コード挿入攻撃
• PAR (OAuth 2.0 Pushed Authorization Requests)
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
© Hitachi, Ltd. 2022. All rights reserved.
Contents
52
1. FAPIとは
2. FAPIに準拠することで防げる攻撃 ~8選~
3. KeycloakにおけるFAPI対応
53
© Hitachi, Ltd. 2022. All rights reserved.
主な特徴
 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
© Hitachi, Ltd. 2022. All rights reserved.
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
© Hitachi, Ltd. 2022. All rights reserved.
FAPIに準拠する際の一般的な課題
FAPIに準拠することで防げる攻撃
1. 認可レスポンス横取り攻撃
• stateを使った対抗策
2. 認可コード横取り攻撃
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
• 分離署名としてのIDトークン
3. アクセストークン横取り攻撃
• アクセストークンへのクライアント証明書のバインド (RFC 8705)
4. リダイレクトURI改ざん攻撃
• リダイレクトURIの完全一致チェック
• パブリッククライアントの非サポート
5. トークンエンドポイントなりすまし攻撃
• クライアント証明書を使ったクライアント認証 (RFC 8705)
6. IdP mix-up攻撃
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
7. 認可レスポンス挿入攻撃
• stateを使った対抗策
8. 認可コード挿入攻撃
• PAR (OAuth 2.0 Pushed Authorization Requests)
• JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
• 設定項目が多すぎる。。。 ・・・ 今回ご紹介した以下のような対抗策を適切に設定する必要がある。
• 適切に設定されているか、つまりFAPIに準拠した状態になっているか、設定ミスによってセ
キュリティホールが生じていないかを確認するのも大変。
56
© Hitachi, Ltd. 2022. All rights reserved.
• クライアントポリシーという機構を使います。
特定の条件(コンディション)に合致するクライアントに、FAPIのようなセキュリティプロファイルを適用することができま
す。
セキュリティプロファイル
コンディション
KeycloakではFAPIをどのように設定するか
myroleというロールを持つ
myscopeというスコープを持つ
FAPI 1.0 - Part 1 Baseline
FAPI 1.0 - Part 2 Advanced
FAPI-CIBA
例えば以下のようなことをクライアントポリシーで設定できます。
に合致する
クライアントに
を適用する。
など など
• これによって何がうれしいか
• 対象のクライアントを自動的にFAPIに準拠させてくれる! ← 細かな設定が不要に!
• クライアントと紐づいたKeycloakへのリクエストがFAPIに準拠しているかどうかを
チェックしてくれる。
• クライアントの設定がFAPIに準拠しているかをチェックしてくれる。
57
© Hitachi, Ltd. 2022. All rights reserved.
セキュリティプロファイル
コンディション
KeycloakではFAPIをどのように設定するか
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
© Hitachi, Ltd. 2022. All rights reserved.
セキュリティプロファイル
コンディション
KeycloakではFAPIをどのように設定するか
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
© Hitachi, Ltd. 2022. All rights reserved.
KeycloakではFAPIをどのように設定するか
ちなみに、FAPIに準拠したリクエストを送るのがハードルが高いという方は・・・
日立からOIDFのCertificationをパスしたFAPIのクライアント実装を公開していますので是非ご活用ください!
参考: https://openid.net/developers/certified/#FAPIRP
60
© Hitachi, Ltd. 2022. All rights reserved.
まとめ
- FAPIの概要のご説明
 OAuth 2.0やOIDCをベースにした、高いレベルのセキュリティを必要とするあら
ゆる市場領域のAPIに適用できる仕様です。
- FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介
1. 認可レスポンス横取り攻撃 ← stateを使った対抗策
2. 認可コード横取り攻撃 ← JARM、分離署名としてのIDトークン
3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書の
バインド
4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック、パブ
リッククライアントの
非サポート
5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクラ
イアント認証
6. IdP mix-up攻撃 ← JARM、分離署名としてのIDトークン
7. 認可レスポンス挿入攻撃 ← stateを使った対抗策
8. 認可コード挿入攻撃 ← PAR、JARM、分離署名としてのIDトークン
- KeycloakにおけるFAPI対応のご紹介
61
© Hitachi, Ltd. 2022. All rights reserved.
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を公開する

More Related Content

What's hot

なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景Tatsuo Kudo
 
KeycloakのDevice Flow、CIBAについて
KeycloakのDevice Flow、CIBAについてKeycloakのDevice Flow、CIBAについて
KeycloakのDevice Flow、CIBAについてHiroyuki Wada
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
 
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideTatsuo Kudo
 
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authleteいまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authleteTatsuo Kudo
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
Keycloak入門-OpenID ConnectによるAPIセキュリティ
Keycloak入門-OpenID ConnectによるAPIセキュリティKeycloak入門-OpenID ConnectによるAPIセキュリティ
Keycloak入門-OpenID ConnectによるAPIセキュリティYuichi Nakamura
 
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦いマイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦いota42y
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例briscola-tokyo
 
Azure ADとIdentity管理
Azure ADとIdentity管理Azure ADとIdentity管理
Azure ADとIdentity管理Naohiro Fujie
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsTatsuo Kudo
 
FAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのためにFAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのためにNat Sakimura
 
基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装Masatoshi Tada
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService PrincipalToru Makabe
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールdcubeio
 
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜Masaru Kurahayashi
 

What's hot (20)

Keycloak入門
Keycloak入門Keycloak入門
Keycloak入門
 
Keycloakの最近のトピック
Keycloakの最近のトピックKeycloakの最近のトピック
Keycloakの最近のトピック
 
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
 
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門するKeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
 
KeycloakのDevice Flow、CIBAについて
KeycloakのDevice Flow、CIBAについてKeycloakのDevice Flow、CIBAについて
KeycloakのDevice Flow、CIBAについて
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
 
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
 
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authleteいまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
IDガバナンス&管理の基礎
IDガバナンス&管理の基礎IDガバナンス&管理の基礎
IDガバナンス&管理の基礎
 
Keycloak入門-OpenID ConnectによるAPIセキュリティ
Keycloak入門-OpenID ConnectによるAPIセキュリティKeycloak入門-OpenID ConnectによるAPIセキュリティ
Keycloak入門-OpenID ConnectによるAPIセキュリティ
 
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦いマイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例
 
Azure ADとIdentity管理
Azure ADとIdentity管理Azure ADとIdentity管理
Azure ADとIdentity管理
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
 
FAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのためにFAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのために
 
基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装基礎からのOAuth 2.0とSpring Security 5.1による実装
基礎からのOAuth 2.0とSpring Security 5.1による実装
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
 
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
 

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

OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護Naohiro Fujie
 
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WGNat Sakimura
 
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向Tatsuo Kudo
 
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチKazuya Sugimoto
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可Hitachi, Ltd. OSS Solution Center.
 
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Tatsuo Kudo
 
Kong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラKong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラbriscola-tokyo
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Hitachi, Ltd. OSS Solution Center.
 
Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向Yuichi Nakamura
 
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...FinTechLabs.io
 
祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE Login祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE LoginNaohiro Fujie
 
AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介ssuser39314d
 
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要Tatsuo Kudo
 
API提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijpAPI提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijpTatsuo Kudo
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割Toru Yamaguchi
 
Authlete overview
Authlete overviewAuthlete overview
Authlete overviewmtisol
 
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizdayTatsuo Kudo
 
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料オラクルエンジニア通信
 
Go_SaaS-Auth0-20190920
Go_SaaS-Auth0-20190920Go_SaaS-Auth0-20190920
Go_SaaS-Auth0-20190920Rica Nakajima
 

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

OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
 
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
 
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
 
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
 
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
 
Kong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラKong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラ
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
 
Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向
 
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
 
祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE Login祝!公式サポート Auth0 + LINE Login
祝!公式サポート Auth0 + LINE Login
 
AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介
 
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要
 
API提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijpAPI提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijp
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
 
Spring12新機能webinar
Spring12新機能webinarSpring12新機能webinar
Spring12新機能webinar
 
Authlete overview
Authlete overviewAuthlete overview
Authlete overview
 
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
 
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容+おまけ資料
 
Go_SaaS-Auth0-20190920
Go_SaaS-Auth0-20190920Go_SaaS-Auth0-20190920
Go_SaaS-Auth0-20190920
 

More from Hitachi, Ltd. OSS Solution Center.

Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Hitachi, Ltd. OSS Solution Center.
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みKeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みHitachi, Ltd. OSS Solution Center.
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...Hitachi, Ltd. OSS Solution Center.
 
Challenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakChallenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakHitachi, Ltd. OSS Solution Center.
 
Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Hitachi, Ltd. OSS Solution Center.
 
What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...Hitachi, Ltd. OSS Solution Center.
 
Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Hitachi, Ltd. OSS Solution Center.
 
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Hitachi, Ltd. OSS Solution Center.
 
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Hitachi, Ltd. OSS Solution Center.
 
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~Hitachi, Ltd. OSS Solution Center.
 
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現Hitachi, Ltd. OSS Solution Center.
 

More from Hitachi, Ltd. OSS Solution Center. (20)

Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みKeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
 
Challenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakChallenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with Keycloak
 
KubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdfKubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdf
 
NGINXでの認可について考える
NGINXでの認可について考えるNGINXでの認可について考える
NGINXでの認可について考える
 
Security Considerations for API Gateway Aggregation
Security Considerations for API Gateway AggregationSecurity Considerations for API Gateway Aggregation
Security Considerations for API Gateway Aggregation
 
Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?
 
What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...
 
Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...
 
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
 
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
 
Apache con@home 2021_sha
Apache con@home 2021_shaApache con@home 2021_sha
Apache con@home 2021_sha
 
Node-RED Installer, Standalone Installer using Electron
Node-RED Installer, Standalone Installer using ElectronNode-RED Installer, Standalone Installer using Electron
Node-RED Installer, Standalone Installer using Electron
 
Hacktoberfest 概要、Node-REDプロジェクト貢献手順
Hacktoberfest 概要、Node-REDプロジェクト貢献手順Hacktoberfest 概要、Node-REDプロジェクト貢献手順
Hacktoberfest 概要、Node-REDプロジェクト貢献手順
 
Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介
 
Node-REDからREST APIに接続
Node-REDからREST APIに接続Node-REDからREST APIに接続
Node-REDからREST APIに接続
 
Node-RED v1.3新機能紹介
Node-RED v1.3新機能紹介Node-RED v1.3新機能紹介
Node-RED v1.3新機能紹介
 
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
 
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
 

Recently uploaded

新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000Shota Ito
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。iPride Co., Ltd.
 
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directoryosamut
 
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツールプレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツールsugiuralab
 
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価sugiuralab
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxAtomu Hidaka
 

Recently uploaded (7)

新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
新人研修のまとめ       2024/04/12の勉強会で発表されたものです。新人研修のまとめ       2024/04/12の勉強会で発表されたものです。
新人研修のまとめ 2024/04/12の勉強会で発表されたものです。
 
PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000PHP-Conference-Odawara-2024-04-000000000
PHP-Conference-Odawara-2024-04-000000000
 
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
Amazon SES を勉強してみる その12024/04/12の勉強会で発表されたものです。
 
20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory20240412_HCCJP での Windows Server 2025 Active Directory
20240412_HCCJP での Windows Server 2025 Active Directory
 
プレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツールプレイマットのパターン生成支援ツール
プレイマットのパターン生成支援ツール
 
プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価プレイマットのパターン生成支援ツールの評価
プレイマットのパターン生成支援ツールの評価
 
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptxIoT in the era of generative AI, Thanks IoT ALGYAN.pptx
IoT in the era of generative AI, Thanks IoT ALGYAN.pptx
 

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

  • 1. © Hitachi, Ltd. 2022. All rights reserved. KeycloakでFAPIに対応した高セキュリティなAPIを公開する CloudNative Days Tokyo 2022 株式会社 日立製作所 田畑 義之
  • 2. 1 © Hitachi, Ltd. 2022. All rights reserved. 自己紹介 田畑 義之 (たばた よしゆき)  株式会社 日立製作所 アーキテクチャセンタ  ソフトウェアエンジニア  GitHub: @y-tabata • 認証認可やAPI関連分野のソリューション開発&コンサルティング  金融、公共、社会、産業分野における API管理基盤や認証認可システムの導入支援 • 認証認可・API管理関連のOSSへのコントリビュート  Keycloak (IAMのOSS)  3scale (API管理のOSS) • 情報発信  Keycloak書籍  ThinkIT/@ITでのWeb記事連載  Apidays/OAuth Security Workshop/CloudNative Daysなど、国内外のイベントでの登壇
  • 3. 2 © Hitachi, Ltd. 2022. All rights reserved. セッション概要 • FAPI (Financial-grade API)という高セキュリティなAPIを公開するための仕様があります。 • システムのセキュリティは高ければ高いほど望ましいですが、実案件では対応コストやユー ザビリティとの トレードオフを見ていかないといけません。  一方で、FAPIに準拠しないにしても、どんな攻撃のリスクがあるかを知り、自システムで はどうやって対策 できるかを考えておくことは大切です。 低い対応コスト/ 高いユーザビリティ 高いセキュリティレベル • FAPIの概要のご説明 • FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介 • IAMを実現するOSSであるKeycloakにおけるFAPI対応のご紹介 本セッションでは・・・
  • 4. © Hitachi, Ltd. 2022. All rights reserved. Contents 3 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  • 5. © Hitachi, Ltd. 2022. All rights reserved. Contents 4 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  • 6. 5 © Hitachi, Ltd. 2022. All rights reserved. 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)
  • 7. © Hitachi, Ltd. 2022. All rights reserved. Contents 6 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  • 8. 7 © Hitachi, Ltd. 2022. All rights reserved. 前提 • OAuth 2.0/OIDCで最も推奨される認可コードフローを前提とします(ハイブリッドフロー を含む)。 ※インプリシットフローやリソースオーナパスワードクレデンシャルズフローだと、説明すべき攻撃方法の数が多くなってしまうため。 正当なユーザ クライアント リソースサーバ 認可サーバ アクセス 認可リクエスト ログイン画面 ログイン 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス 画面表示
  • 9. 8 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 ※参考: FAPI 2.0 Attacker Model https://openid.net/specs/fapi-2_0-attacker-model-00.html
  • 10. 9 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント 正当なユーザ 正当なユーザとしてログインすることで以下のようなことができる。 • クライアントに設定している情報からの、正当なユーザの個人情報の取得 →住所や電話番号、プライベートな写真の取得など。 • 正当なユーザの周辺のユーザへの攻撃 →「友達」として登録されているユーザへのプリペイドカード番号の要求など。
  • 11. 10 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント 正当なユーザ リソースサーバ 正当なユーザのリソースにアクセスすることで以下のようなことができる。 • リソースサーバに保存している情報からの、正当なユーザの個人情報の取得 →保存しているドキュメントや写真、動画の取得など。 • 金融取引をトリガーするために利用できるAPIのコール →正当なユーザの口座から攻撃者の口座への送金のリクエストなど。
  • 12. 11 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント リソースサーバ 攻撃者 攻撃者 正当なユーザに攻撃者としてログインさせたり、攻撃者のリソースにアクセスさせることで以下のようなことができる。 • 攻撃者アカウントへ登録された正当なユーザの情報の取得 →正当なユーザが誤って攻撃者のアカウントへ登録してしまった個人情報や口座情報の取得など。 • 正当なユーザのアカウント情報を用いた他システムへのログイン →正当なユーザが誤って攻撃者のアカウントへ紐づけてしまった他システムのアカウントを用いたログインなど。
  • 13. 12 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 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
  • 14. 13 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 自作メッセージを 送付 改ざんした メッセージを送付 正当なメッセージを 送付
  • 15. 14 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 2. 正当なユーザにリンクを送付して、そこに訪問させることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 攻撃者のサイト リンクを 送付 訪問
  • 16. 15 © Hitachi, Ltd. 2022. All rights reserved. 不正なWiFiアクセスポイントや 侵害したネットワーク内 まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 復号化キーがなければ、 中身の読み取りまではできない。 傍受 ブロック 改ざん
  • 17. 16 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができ る。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ ブラウザの 履歴の入手 認可サーバや 手前のリバプロのログの入手 認可リクエストや 認可レスポンスを読み取る 認可リクエスト
  • 18. 17 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。 クライアント管理者 攻撃者 クライアント リソースサーバ 認可サーバ エンドポイント 変更の通知 攻撃者のサーバ 正規のトークン リクエスト 誘導された トークンリクエスト トークン リクエストを取得 クライアント設定の変更
  • 19. 18 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレ スポンスを改ざんすることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ リバプロ APIリクエスト APIリクエスト 盗聴・改ざん TLS 終端
  • 20. 19 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 攻撃者配下の 認可サーバ 7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加 し、認可サーバからトークンを取得することができる。 メール等で 誘導 実際の やり取り トークンを取得 正当な やり取り 正当な やり取り 正当なユーザが 想定したやり取り
  • 21. 20 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  • 22. 21 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  • 23. 22 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 正当なユーザの認可レスポンスを盗聴して自身のブラウザからクライアントに流し込めれば、正当なユー ザとしてクライアントにログインできる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス トークンリクエスト トークンレスポンス 正当なユーザ としてログイン GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org ※そのまま送る。 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 &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com
  • 24. 23 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com セッションに stateを保存 認可レスポンスに 同一のstateを付与 セッションのstateと 認可レスポンスの stateを比較検証 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org
  • 25. 24 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。攻撃者から送られてきた認可レスポン スには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検知でき る。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス セッションに stateを保存 盗聴 認可レスポンス GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org ※そのまま送る。 認可レスポンスに 同一のstateを付与 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 認可レスポンスと 同一のstateが セッションに無い ことを検知
  • 26. 25 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 事前に認可リクエストをトリガーし、stateを払い出しておく。正当なユーザの認可コードのみを盗聴し て攻撃者用の認可レスポンスを作成し、自身のブラウザからクライアントに流し込めれば、正当なユーザ としてクライアントにログインできる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス トークンリクエスト トークンレスポンス 正当なユーザ としてログイン 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 /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org ※stateは自身のものを流用。 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com
  • 27. 26 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 署名を検証 GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。
  • 28. 27 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可 レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス アクセス 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org ※stateを自身のものを変えたとする。 GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。 署名の検証で 改ざんを検知 GET /authorize? response_type=code … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com
  • 29. 28 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー ドとstateのハッシュ値を含める。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code id_token &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 署名とハッシュ値 を検証 GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj &id_token=eyJr… HTTP/1.1 Host: client.example.org <IDトークン> { "sub": "1001", "aud": "s6BhdRkqt3", "c_hash": "QR2z…", "s_hash": "9s6C…", "auth_time": 1594140090, "iss": "https://server.example.com/", "exp": 1594140390, "iat": 1594140090 } ※署名あり。
  • 30. 29 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー ドとstateのハッシュ値を含める。IDトークンの署名とそれらハッシュ値を検証することで、クライアン トは認可レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス アクセス 認可リクエスト GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk &id_token=eyJr… HTTP/1.1 Host: client.example.org ※stateを自身のものに変えたとする。 署名とハッシュ値の 検証で改ざんを 検知 GET /authorize? response_type=code id_token … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj &id_token=eyJr… HTTP/1.1 Host: client.example.org <IDトークン> { "sub": "1001", "aud": "s6BhdRkqt3", "c_hash": "QR2z…", "s_hash": "9s6C…", "auth_time": 1594140090, "iss": "https://server.example.com/", "exp": 1594140390, "iat": 1594140090 } ※署名あり。 GET /authorize? response_type=code id_token &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com
  • 31. 30 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  • 32. 31 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 TLS終端するリソースサーバの手前のリバプロのログからAPIリクエスト(アクセストークン含む)を盗聴 できれば、正当なユーザのリソースにアクセスできるアクセストークンを取得できる。 リソースサーバ 認可サーバ 攻撃者 APIリクエスト 盗聴 APIリクエス ト アクセストークン の取得 GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… ※そのまま送る GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… クライアント リバプロ
  • 33. 32 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド (RFC 8705) クライアント証明書をアクセストークンにバインドする。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス 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 クライアント証明書 を相互TLSで提示 リソースサーバ APIリクエスト クライアント証明書の ハッシュ値を比較検証 アクセストークンに クライアント証明書 のハッシュ値を バインドする クライアント証明書 を相互TLSで提示
  • 34. 33 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド (RFC 8705) クライアント証明書をアクセストークンにバインドする。たとえアクセストークンを取得しても攻撃者は クライアント証明書の秘密鍵は取得できず、その所持をリソースサーバに示すことができないため、保護 リソースを取得できなくなる。 リソースサーバ 認可サーバ 攻撃者 アクセス 盗聴 APIリクエス ト アクセストークン の取得 GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… ※そのまま送る GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… クライアント リバプロ 正当なユーザ APIリクエスト 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス クライアント証明書を提示しない/ クライアント証明書が一致しない 不正なリクエストを検知 クライアント証明書の秘密鍵は 提示されないので奪えない
  • 35. 34 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 リダイレクトURIを改ざんした認可リクエストを正当なユーザに送り付け、攻撃者のサイトで認可コード を盗聴して自身で 認可サーバに送ることができれば、正当なユーザのリソースにアクセスできるアクセストークンを取得で きる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト 認証 認可レスポンス 傍受 トークンリクエスト トークンレスポンス APIリクエスト アクセストークン の取得 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: attacker.example.org 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://attacker.example.org/cb &client_id=s6BhdRkqt3
  • 36. 35 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック 事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの 完全一致を検証する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com 事前に登録された リダイレクトURIと 認可リクエストの リダイレクトURIを 比較検証 事前にリダイレクトURIを 完全URIで登録
  • 37. 36 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック 事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの 完全一致を検証する。 攻撃者が送り付けた認可リクエストはリダイレクトURIが一致しないため、認可サーバは攻撃を検知でき る。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com リダイレクトURIの完全一致の 検証でリダイレクトURIの不正 を検知
  • 38. 37 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート トークンエンドポイントでのクライアント認証を強制する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス 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 &client_secret=jngso0033i クライアント認証を強制し クライアントクレデンシャル を比較検証
  • 39. 38 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート トークンエンドポイントでのクライアント認証を強制する。アクセストークンの入手にはクライアントク レデンシャルの取得も必要になり、盗聴した認可コードだけではアクセストークンを取得できなくなる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト 認証 認可レスポンス 傍受 トークンリクエスト GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: attacker.example.org クライアントクレデンシャルを 提示しない不正なリクエストを 検知 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://attacker.example.org/cb &client_id=s6BhdRkqt3
  • 40. 39 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 トークンエンドポイントの変更通知をクライアント管理者に送り付けてエンドポイントの設定を変更させ、 攻撃者のサイトでトークンリクエストを取得できれば、認可コードもクライアントクレデンシャルも取得 でき、それらでアクセストークンを取得できる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサーバ 攻撃者 エンドポイント 変更通知 アクセス 認証 認可レスポンス 傍受 トークンリクエスト トークンレスポンス APIリクエスト アクセストークン の取得 POST /token HTTP/1.1 Host: attacker.example.org Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3 &client_secret=jngso0033i クライアント管理者クライアント エンドポイント 変更 認可リクエスト トークンリクエスト 認可コードもクライアント クレデンシャルも取得できる
  • 41. 40 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認 証 (RFC 8705) クライアント証明書をクライアント認証に用いる。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス 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 クライアント証明書を使った クライアント認証を強制し クライアント証明書を比較検証
  • 42. 41 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認 証 (RFC 8705) クライアント証明書をクライアント認証に用いる。トークンリクエストを取得しても攻撃者はクライアン ト証明書の秘密鍵は取得できず、その所持を認可サーバに示すことができないため、クライアント認証に 失敗しアクセストークンを取得できなくなる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサーバ 攻撃者 エンドポイント 変更通知 アクセス 認証 認可レスポンス 傍受 トークンリクエスト POST /token HTTP/1.1 Host: attacker.example.org Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3 クライアント管理者クライアント エンドポイント 変更 認可リクエスト トークンリクエスト クライアント証明書の秘密鍵は 提示されないので奪えない クライアント証明書を提示しない 不正なリクエストを検知
  • 43. 42 © Hitachi, Ltd. 2022. All rights reserved. 認可リクエスト 自身に対する 認可リクエストをトリガ FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 6. IdP mix-up攻撃 認可サーバを準備し、正当なクライアントの認可サーバとして、かつ正当な認可サーバのクライアントと して登録する。 正当なユーザを攻撃者配下の認可サーバに誘導することで、アクセストークンを取得できる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者 アクセスを誘導 認証 認可レスポンス 傍受 APIリクエスト アクセストークン の取得 クライアント トークンリクエスト 正当なクライアントの認可サーバ として登録されている 攻撃者配下の 認可サーバ 認可リクエスト トークンリクエスト トークンレスポンス 正当な認可サーバのクライアント として登録されている 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=o3ksnRuew2 GET /cb? code=SplxlOBeZQQYbY… &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=o3ksnRuew2 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com
  • 44. 43 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 6. IdP mix-up攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。JWT内のissクレームとaudクレームを検証す ることで、クライアントは認可レスポンスの不正を検知できる。 認可リクエスト 自身に対する 認可リクエストをトリガ 正当なユーザ リソースサーバ 認可サーバ 攻撃者 アクセスを誘導 認証 認可レスポンス クライアント 攻撃者配下の 認可サーバ 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &response_mode=jwt &client_id=o3ksnRuew2 … HTTP/1.1 Host: attacker.example.com <JARMレスポンス> { "aud": "o3ksnRuew2", "iss": "https://server.example.com/", … } ※署名あり。 issクレームとaudクレームの検証で 意図した認可サーバからのレスポンスではないことや 自身宛てのレスポンスではないことを検知
  • 45. 44 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  • 46. 45 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 攻撃者の認可レスポンスを正当なユーザに送り付け、正当なユーザのブラウザからクライアントに流し込 ませることができれば、攻撃者としてクライアントにログインさせることができる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス トークンリクエスト トークンレスポンス 攻撃者として ログイン GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org ※そのまま送る。 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 &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com
  • 47. 46 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 7. 認可レスポンス挿入攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。正当なユーザから送られてきた認可レ スポンスには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検 知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org ※そのまま送る。 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com 認可レスポンスと 同一のstateが セッションに無い ことを検知
  • 48. 47 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 事前に正当なユーザの認可リクエストを盗聴し、stateを取得しておく。攻撃者の認可コードのみを使っ て正当なユーザ用の認可レスポンスを作成し、クライアントに流し込ませることができれば、攻撃者とし てクライアントにログインさせることができる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス トークンリクエスト トークンレスポンス 攻撃者として ログイン 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 /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org ※stateは正当なユーザのものを流用。 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 盗聴
  • 49. 48 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests) 認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに 登録する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス PARリクエスト PARレスポンス POST /par HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn:ietf:params:oauth:client- assertion-type:jwt-bearer &client_assertion=eyJr… &request=eyJr… &client_id=s6BhdRkqt3 <リクエストオブジェクト> { "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", "state": "af0ifjsldkj", "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 Host: server.example.com 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にまとめて送信 認可リクエストに パラメータは直接 含まれない
  • 50. 49 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 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 Host: server.example.com 盗聴 PARリクエスト PARレスポンス POST /par HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn:ietf:params:oauth:client- assertion-type:jwt-bearer &client_assertion=eyJr… &request=eyJr… &client_id=s6BhdRkqt3 <リクエストオブジェクト> { "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", "state": "af0ifjsldkj", "exp": 1594140390, "client_id": "s6BhdRkqt3“, "code_challenge": "K2-l…", "code_challenge_method": "S256" } ※署名あり。 stateを盗聴できないので 攻撃が成立しない (正当なユーザ用の認可 レスポンスを作成できない)
  • 51. 50 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可 レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス アクセス 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org ※stateを正当なユーザのものに 変えたとする。 GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 盗聴 GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。 署名の検証で 改ざんを検知
  • 52. 51 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 ~ まとめ ~ 1. 認可レスポンス横取り攻撃 • stateを使った対抗策 2. 認可コード横取り攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 分離署名としてのIDトークン 3. アクセストークン横取り攻撃 • アクセストークンへのクライアント証明書のバインド (RFC 8705) 4. リダイレクトURI改ざん攻撃 • リダイレクトURIの完全一致チェック • パブリッククライアントの非サポート 5. トークンエンドポイントなりすまし攻撃 • クライアント証明書を使ったクライアント認証 (RFC 8705) 6. IdP mix-up攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 7. 認可レスポンス挿入攻撃 • stateを使った対抗策 8. 認可コード挿入攻撃 • PAR (OAuth 2.0 Pushed Authorization Requests) • JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
  • 53. © Hitachi, Ltd. 2022. All rights reserved. Contents 52 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  • 54. 53 © Hitachi, Ltd. 2022. All rights reserved. 主な特徴  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)
  • 55. 54 © Hitachi, Ltd. 2022. All rights reserved. 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) 絶賛作業中!
  • 56. 55 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠する際の一般的な課題 FAPIに準拠することで防げる攻撃 1. 認可レスポンス横取り攻撃 • stateを使った対抗策 2. 認可コード横取り攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 分離署名としてのIDトークン 3. アクセストークン横取り攻撃 • アクセストークンへのクライアント証明書のバインド (RFC 8705) 4. リダイレクトURI改ざん攻撃 • リダイレクトURIの完全一致チェック • パブリッククライアントの非サポート 5. トークンエンドポイントなりすまし攻撃 • クライアント証明書を使ったクライアント認証 (RFC 8705) 6. IdP mix-up攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 7. 認可レスポンス挿入攻撃 • stateを使った対抗策 8. 認可コード挿入攻撃 • PAR (OAuth 2.0 Pushed Authorization Requests) • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 設定項目が多すぎる。。。 ・・・ 今回ご紹介した以下のような対抗策を適切に設定する必要がある。 • 適切に設定されているか、つまりFAPIに準拠した状態になっているか、設定ミスによってセ キュリティホールが生じていないかを確認するのも大変。
  • 57. 56 © Hitachi, Ltd. 2022. All rights reserved. • クライアントポリシーという機構を使います。 特定の条件(コンディション)に合致するクライアントに、FAPIのようなセキュリティプロファイルを適用することができま す。 セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか myroleというロールを持つ myscopeというスコープを持つ FAPI 1.0 - Part 1 Baseline FAPI 1.0 - Part 2 Advanced FAPI-CIBA 例えば以下のようなことをクライアントポリシーで設定できます。 に合致する クライアントに を適用する。 など など • これによって何がうれしいか • 対象のクライアントを自動的にFAPIに準拠させてくれる! ← 細かな設定が不要に! • クライアントと紐づいたKeycloakへのリクエストがFAPIに準拠しているかどうかを チェックしてくれる。 • クライアントの設定がFAPIに準拠しているかをチェックしてくれる。
  • 58. 57 © Hitachi, Ltd. 2022. All rights reserved. セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか 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ロールを取ると
  • 59. 58 © Hitachi, Ltd. 2022. All rights reserved. セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか 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ロールを持つクライアントでも
  • 60. 59 © Hitachi, Ltd. 2022. All rights reserved. KeycloakではFAPIをどのように設定するか ちなみに、FAPIに準拠したリクエストを送るのがハードルが高いという方は・・・ 日立からOIDFのCertificationをパスしたFAPIのクライアント実装を公開していますので是非ご活用ください! 参考: https://openid.net/developers/certified/#FAPIRP
  • 61. 60 © Hitachi, Ltd. 2022. All rights reserved. まとめ - FAPIの概要のご説明  OAuth 2.0やOIDCをベースにした、高いレベルのセキュリティを必要とするあら ゆる市場領域のAPIに適用できる仕様です。 - FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 2. 認可コード横取り攻撃 ← JARM、分離署名としてのIDトークン 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書の バインド 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック、パブ リッククライアントの 非サポート 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクラ イアント認証 6. IdP mix-up攻撃 ← JARM、分離署名としてのIDトークン 7. 認可レスポンス挿入攻撃 ← stateを使った対抗策 8. 認可コード挿入攻撃 ← PAR、JARM、分離署名としてのIDトークン - KeycloakにおけるFAPI対応のご紹介
  • 62. 61 © Hitachi, Ltd. 2022. All rights reserved. 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.