「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api

FinTech X Security-JAWS 勉強会 #01
「金融API向けOAuth」にみるOAuthプロファイリングの実際
2017-06-16
工藤達雄 http://www.linkedin.com/in/tatsuokudo
Cyber Consulting Services
NRI SecureTechnologies, Ltd.

Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1
工藤達雄 http://www.linkedin.com/in/tatsuokudo/
@tkudos / https://fb.me/tkudo
サン・マイクロシステムズ (1998~2008)
野村総合研究所 (2008~)
OpenIDファウンデーション・ジャパン (2013~2014)
NRIセキュアテクノロジーズ (2014~)
▪ 現在はデジタル・アイデンティティとAPIを専門とする
コンサルティングに従事
自己紹介

OpenID Foundation 配下のワーキンググループが策定を進めている
「Financial API (FAPI)」 https://openid.net/wg/fapi/ をネタに
API セキュリティにおける OAuth 2.0 適用（プロファイリング）の
ベストプラクティスとその先について紹介します。
本プレゼンテーションの内容

OAuthとは?
APIアクセス（フルオープン）
API
サーバー
APP
APIクライアント
HTML5
WEBSITE
1
GET /items/12345 HTTP/1.1

OAuthとは?
APIアクセスを「クライアントのクレデンシャル」で制限する
API
サーバー
APP
APIクライアント
HTML5
WEBSITE
1 ******
GET /items/12345 HTTP/1.1
x-api-key: ******
クライアントのクレデンシャルを要求

OAuthとは?
「クライアントのクレデンシャル」をもとに付与した「トークン」でAPIアクセスを制限する
OAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・グラント」
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
WEBSITE
2 2. アクセストークン
提供
3
3. アクセストークンを
使ってAPIアクセス
1
1. クライアントのクレデンシャルを
使ってトークンリクエスト ******
アクセストークンを要求
クライアントのクレデンシャルを以て
アクセストークンを提供する

OAuthとは?
リソースオーナーのID/パスワードを使ってAPIのアクセスを制限したい場合には?
リソースオーナー
リソース
サーバー
APP
クライアント
HTML5
WEBSITE
0
0. ID/パスワードを登録
ユーザーID: johndoe
パスワード: ******
1
1. ID/パスワードを
パスワード: ******
ID/パスワードを要求

OAuthとは?
「リソースオーナーのID/パスワード」をもとに付与した「トークン」でAPIアクセスを制限する
OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・クレデンシャル・グラント」 ※非推奨
リソース
サーバー
APP
認可
サーバー
クライアント
HTML5
WEBSITEWEBSITE
0
0. ID/パスワードを登録
パスワード: ******
2 2. アクセストークン
提供
3
1
1. クライアントのクレデンシャルと
ユーザーのID/パスワードを
使ってトークンリクエスト
クライアントのクレデンシャル: ******
パスワード: ******
リソースオーナーのクレデンシャル
を以てアクセストークンを提供する

OAuthとは?
「認可コード」をもとに付与した「トークン」でAPIアクセスを制限する
OAuth 2.0 (RFC 6749) の「認可コード・グラント」
リソース
サーバー
認可
サーバー
クライアント
WEBSITE
0
0. リソースへのアクセスを
リクエスト
7
ユーザーエージェント
1
1. 認可リクエスト
（ブラウザ
リダイレクト）
2
2. ユーザー認証 & クライアントへの権限委譲の確認
4
4. 認可コード提供
（ブラウザリダイレクト）
6
6. アクセストークン
提供
3
3. OK!
パスワード: ******
5
5. クライアントの
クレデンシャルと
認可コードを使って
トークンリクエスト
******
認可コードを以て
アクセストークンを提供する

「Amazon API Gateway with カスタム・オーソライザー」と「外部認可サーバー」による構成例
API Gatewayは認可サーバーと連携し、クライアントから受け取ったアクセストークンを検証する
クライアント
WEBSITE
0 7
1
2
3
4
6
5 ******
API
Gateway
“カスタム・
オーソライザー”
（Lambda関数）
リソースサーバー
認可サーバー
(e.g. Authlete, Hydra, WSO2 etc.)
認可依頼
検証依頼検証結果
ポリシー
Lambda 関数やEC2上
のエンドポイント、あるい
は外部のエンドポイントへ
参考情報:
http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/use-custom-authorizer.html
http://qiita.com/TakahikoKawasaki/items/b372ab49da0a9aedb76a
https://blogs.edwardwilde.com/2017/01/12/creating-an-oauth2-custom-lamda-authorizer-for-use-with-amazons-aws-api-gateway-using-hydra/
http://www.dushantech.com/2016/10/wso2-is-with-amazon-api-gateway.html

OAuthは「プロトコル」ではなく「フレームワーク」。
実際のサービスに適用するにはそこからいろいろな決めごとを考えていく（プロファイリングする）必要がある
リソース
サーバー
認可
サーバー
クライアント
WEBSITE
0 7
1
2
3
4
6
5
認可リクエストの形式
リソースオーナーの認証・同意方法
トークンリクエスト
の形式
トークンレスポンス
の形式
アクセストークンの
ライフサイクル
アクセストークンの
利用方法
******
クライアント
認証の方式

決めごとの例
 クライアント側に用意する「認可コードの受け口」
 クライアントは認可リクエストを認可サーバーに送信する際に
redirect_uriパラメーターを用いて、どの「リダイレクション・エンド
ポイント」に認可コードを送信してほしいかを指定することができる
 認可サーバーはリソースオーナーとのインタラクションを行った後、
ユーザーエージェントに、「リダイレクション・エンドポイントへの
リダイレクトレスポンス」として認可コードを返却する。これにより
ユーザーエージェントは「リダイレクション・エンドポイント」への
リクエストとして、そのパラメーターを自動的に送信することになる
クライアントの「リダイレクション・エンドポイント」
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
リダイレクション
エンドポイント
32
GET /authorize?
response_type=code&
client_id=s6BhdRkqt3&
scope=message.readonly&
state=3af23asl0989gnv&
redirect_uri=https%3A%2F%2F
client%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com
4. 認可レスポンス
HTTP/1.1 302 Found
Location:
https://client.example.com/cb
?code=SplxlOBeZQQYbYS6WxSbIA&
state=3af23asl0989gnv

決めごとの例
 仕様上(RFC 6749 3.1.2.2)、クライアントのリダイレクション・
エンドポイントは認可サーバーに事前登録すべき (SHOULD)
 “The authorization server SHOULD require all clients to register their
redirection endpoint prior to utilizing the authorization endpoint”
 “The authorization server SHOULD require the client to provide the
complete redirection URI”
 これを認可サーバーはどう解釈するか?
1. “SHOULD” であり、事前登録しなくてもよい。
クライアントは認可リクエスト時に任意のURIを指定可能
2. リダイレクション・エンドポイントのFQDNのみ事前登録。
URIパスやパラメーターは動的に追加可能
3. リダイレクション・エンドポイントのドメインのみ事前登録。
サブドメインは動的に指定可能
4. リダイレクション・エンドポイントとして完全なURIを事前登録。
それと一致しないURIは指定不可
クライアントの「リダイレクション・エンドポイント」 (cont.)
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:
redirect_uriを
どう扱うか?

決めごとの例
 クライアントが認可リクエストのパラメーターとして設定する値
 認可リクエストにstateパラメーターの値が設定されていた場合
認可サーバーはその値を認可レスポンスに設定する
 クライアントはこの値を用いて、送信した認可リクエストと、
受信した認可レスポンスとをひもづけることができる
認可リクエストの “state” パラメーター
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:

決めごとの例
 仕様上(RFC 6749 4.1.1)、stateパラメーターの利用は推奨
(RECOMMENDED)
 “RECOMMENDED. An opaque value used by the client to
maintain state between the request and callback.”
 “The parameter SHOULD be used for preventing cross-site
request forgery as described in Section 10.12.”
 これをクライアントはどう解釈するか?
1. “RECOMMENDED” であり、設定しなくても良い
2. クライアントはすべての認可リクエストに同じstate値をセットする
3. クライアントは認可リクエストごとにstate値をセットする
a. セッションIDをセットする
b. セッションIDのハッシュなどをセットする
認可リクエストの “state” パラメーター (cont.)
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
GET /authorize?
response_type=code&
HTTP/1.1
HTTP/1.1 302 Found
Location:
クライアントは
stateの値を
どう作るか?

決めごとの例
 仕様上 (RFC 6749 2.3)、認可サーバーはクライアント認証に任意の
手段を用いることができ、そのひとつとしてクライアントパスワードの
用法が定義されている (同 2.3.1)
 “The authorization server MAY accept any form of client authentication
meeting its security requirements.”
 “Clients in possession of a client password MAY use the HTTP Basic
authentication scheme”
 一方、仕様上 (同 10.1)、単なるクライアントパスワードではない
より強固なクライアント認証を行うことが推奨されている
 “The authorization server is encouraged to consider stronger client
authentication means than a client password.”
 これを認可サーバーはどう解釈するか?
1. クライアントパスワードを使って認証
2. 加えてIPアドレス制限
3. あるいはTLS双方向認証
4. またはSAMLやJWTなどの「セキュリティ・アサーション」による認証
トークンリクエストにおけるクライアント認証
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
14
6
6
5 ******
POST /token HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Base64(client_id:client_secret)
で良い?

金融分野のAPIにおけるOAuthの「詳細仕様の標準化」 → プロファイルの標準化が期待されてる（んだと思う）
オープンAPIのあり方に関する検討会報告書－オープン・イノベーションの活性化に向けて－【中間的な整理（案）】 https://www.zenginkyo.or.jp/fileadmin/res/news/news290316_2.pdf

OpenID Foundation “Financial API (FAPI) WG”
http://openid.net/wg/fapi/
 策定を進めている仕様
 APIセキュリティ・プロファイル
▪ Part 1: 「読み出し専用」 API
▪ Part 2: 「読み書き」 API
 API仕様
▪ Part 3: オープンデータAPI
▪ Part 4: 保護対象データAPIおよびスキーマ - 「読み出し専用」
▪ Part 5: 保護対象データAPIおよびスキーマ - 「読み書き」
 認可サーバー、クライアント、
リソースサーバーに対する
「セキュリティ条項 (Security
Provisions)」を規定

FAPI
 クライアントの「リダイレクション・エンドポイント」
 認可サーバーはクライアントのリダイレクトURIを事前登録すること
 認可サーバーはクライアントからの認可リクエストに
redirect_uriパラメーターが指定されていない場合には処理を中断すること
 認可サーバーは、認可リクエスト内のredirect_uriパラメーターの値を
事前登録したリダイレクトURIと比較し、完全一致しない場合には
処理を中断すること
 認可リクエストの “state” パラメーター
 クライアントは有効なCSRF対策を実装すること
 トークンリクエストにおけるクライアント認証
 認可サーバーはTLS双方向認証 or JWSクライアントアサーションを用いて
クライアント認証を行うこと
たとえば前述の「決めごとの例」はFAPIではどうなっているか?
“Part 1: 「読み出し専用」 APIセキュリティ・プロファイル”
リソース
オーナー
認可
サーバー
クライアント
WEBSITE
ユーザー
エージェント
32
14
6
6
5 ******
リダイレクション・
エンドポイントの
厳密なチェック
クライアント認証は
Basic認証不可
CSRF対策
（i.e. 適切な
stateの利用）

FAPI
5.2.2 Authorization Server
The Authorization Server
1. shall support confidential clients
2. should support public clients
3. shall provide a client secret that adheres to the requirements in section 16.19 of OIDC if a symmetric
key is used
4. shall authenticate the confidential client at the Token Endpoint using one of the following methods: 1.
TLS mutual authentication TLSM; 2. JWS Client Assertion using the client_secret or a private key as
specified in section 9 of OIDC
5. shall require a key of size 2048 bits or larger if RSA algorithms are used for the client authentication
6. shall require a key of size 160 bits or larger if elliptic curve algorithms are used for the client
authentication
7. shall support RFC7636 with S256 as the code challenge method if it supports public clients
8. shall require Redirect URIs to be pre-registered
9. shall require the redirect_uri parameter in the authorization request
10. shall require the value of redirect_uri to exactly match one of the pre-registered Redirect URIs
11. shall require user authentication at LoA 2 as defined in X.1254 or more
12. shall require explicit consent by the user to authorize the requested scope if it has not been
previously authorized
“Part 1: 「読み出し専用」 APIセキュリティ・プロファイル” における認可サーバーのセキュリティ条項
（認可サーバーだけではなくクライアントとリソースサーバーについてもそれぞれ別途セキュリティ条項があることに留意）
Source: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md
13. shall verify that the Authorization Code (section 1.3.1 of RFC6749) has not been
previously used if possible
14. shall return token responses that conform to section 4.1.4 of RFC6749
15. shall return the list of allowed scopes with the issued access token
16. shall provide opaque non-guessable access tokens with a minimum of 128 bits as
defined in section 5.1.4.2.2 of RFC6819
17. should clearly identify long-term grants to the user during authorization as in 16.18 of
OIDC
18. should provide a mechanism for the end-user to revoke access tokens and refresh
tokens granted to a Client as in 16.18 of OIDC
19. shall support the authentication request as in Section 3.1.2.1 of OIDC
20. shall perform the authentication request verification as in Section 3.1.2.2 of OIDC
21. shall authenticate the user as in Section 3.1.2.2 and 3.1.2.3 of OIDC
22. shall provide the authentication response as in Section 3.1.2.4 and 3.1.2.5 of OIDC
depending on the outcome of the authentication
23. shall perform the token request verification as in Section 3.1.3.2 of OIDC
24. shall issue an ID Token in the token response when openid was included in the
requested scope as in Section 3.1.3.3 of OIDC with its sub value corresponding to the
authenticated user and optional acr value in ID Token

FAPI
 Part 1のセキュリティ条項を遵守した上で、さらに追加の対策が求められている
 私的ハイライト:
 OpenID Connect の「ハイブリッド・フロー」
▪ 認可サーバーは、クライアントからの認可リクエストにおいて、response_type
として「code id_token」もしくは「code id_token token」を要求すること
 「分離署名」としてのIDトークン
▪ 認可サーバーは、認可レスポンスへの「分離署名」として機能する
IDトークンを返却すること
 リクエスト・オブジェクト
▪ 認可サーバーはクライアントに対し、request もしくは request_uriパラメータを
用いて認可リクエストを JWS signed JWT とするよう求めること
 “Holder of Key”
▪ 認可サーバーは「holder of key」の認可コード、アクセストークン、リフレッシュ
トークンを返却すること。また「holder of key」機構として、OAuth 2.0 Token
Binding もしくは Mutual TLS Profiles for OAuth Clients をサポートすること
“Part 2: 「読み書き」 APIセキュリティ・プロファイル” に盛り込まれる（であろう）セキュリティ条項
Source: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

OAuth を活用してAPIアクセス認可を実現する
ためには「プロファイリング」が必要です
金融向けAPIはもとより、それに限らず一般的
にOAuthのプロファイリングを行う際には、
OpenID Foundation の Financial API WG が
策定を進めている仕様群は要チェックです
まとめ

 使える「車輪」や「車輪の部品」はたくさんある
 OAuthの拡張仕様など https://datatracker.ietf.org/wg/oauth/documents/
 OpenID Connect http://openid.net/developers/specs/
 For starters…
 RFC 6819: OAuth 2.0の脅威モデルとセキュリティ検討 https://tools.ietf.org/html/rfc6819, https://openid-foundation-japan.github.io/rfc6819.ja.html （和訳）
▪ “This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a
comprehensive threat model for the OAuth 2.0 protocol.”
 draft-ietf-oauth-security-topics: OAuthセキュリティ・トピックス https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics
▪ “This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document
for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and
eventually recommend best current practice and also OAuth extensions needed to cope with the respective security
threats.”
 draft-ietf-oauth-native-apps: ネイティブ・アプリケーション向けのOAuth 2.0 https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps
▪ “OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's
browser. This specification details the security and usability reasons why this is the case, and how native apps and
authorization servers can implement this best practice.”
DO IT YOURSELF!!

[PR]☺
 ”APIセキュリティ” で検索していただければ幸いです
NRIセキュアの「APIセキュリティコンサルティングサービス」
https://www.nri-secure.co.jp/service/consulting/apisecurity.html

「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api

「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à 「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api

Similaire à 「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api (20)

Plus de Tatsuo Kudo

Plus de Tatsuo Kudo (20)

「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api