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

FinTech X Security-JAWS 勉強会 #01

「金融API向けOAuth」にみるOAuthプロファイリングの実際

2017-06-16

工藤達雄 http://www.linkedin.com/in/tatsuokudoCyber Consulting ServicesNRI SecureTechnologies, Ltd.

http://www.linkedin.com/in/tatsuokudo

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を専門とするコンサルティングに従事

自己紹介

http://www.linkedin.com/in/tatsuokudo/

https://fb.me/tkudo


OpenID Foundation 配下のワーキンググループが策定を進めている

「Financial API (FAPI)」 https://openid.net/wg/fapi/ をネタに

API セキュリティにおける OAuth 2.0 適用（プロファイリング）の

ベストプラクティスとその先について紹介します。

本プレゼンテーションの内容

https://openid.net/wg/fapi/


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.1x-api-key: ******

クライアントのクレデンシャルを要求


OAuthとは?

「クライアントのクレデンシャル」をもとに付与した「トークン」でAPIアクセスを制限するOAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・グラント」

リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITE

2 2. アクセストークン

提供

3

3. アクセストークンを

使ってAPIアクセス

11. クライアントのクレデンシャルを

使ってトークンリクエスト ******

アクセストークンを要求

クライアントのクレデンシャルを以て

アクセストークンを提供する


OAuthとは?

リソースオーナーのID/パスワードを使ってAPIのアクセスを制限したい場合には?

リソースオーナー

リソース

サーバー

APP

クライアント

HTML5

WEBSITE

0

0. ID/パスワードを登録

ユーザーID: johndoeパスワード: ****** 1

1. ID/パスワードを


ユーザーID: johndoeパスワード: ******

ID/パスワードを要求


OAuthとは?

「リソースオーナーのID/パスワード」をもとに付与した「トークン」でAPIアクセスを制限するOAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・クレデンシャル・グラント」 ※非推奨


リソース

サーバー

APP

認可

サーバー

クライアント

HTML5

WEBSITEWEBSITE

0

0. ID/パスワードを登録


2 2. アクセストークン

提供

3



1

1. クライアントのクレデンシャルと

ユーザーのID/パスワードを

使ってトークンリクエスト

クライアントのクレデンシャル: ******ユーザーID: johndoeパスワード: ******


リソースオーナーのクレデンシャル

を以てアクセストークンを提供する


OAuthとは?

「認可コード」をもとに付与した「トークン」でAPIアクセスを制限するOAuth 2.0 (RFC 6749) の「認可コード・グラント」


リソース

サーバー

認可

サーバー

クライアント

WEBSITE0

0. リソースへのアクセスを

リクエスト

7



ユーザーエージェント

1

1. 認可リクエスト

（ブラウザ

リダイレクト）

22. ユーザー認証 & クライアントへの権限委譲の確認

4

4. 認可コード提供

（ブラウザリダイレクト）

66. アクセストークン

提供

33. OK!


5

5. クライアントの

クレデンシャルと

認可コードを使って

トークンリクエスト

******


認可コードを以て

アクセストークンを提供する


「Amazon API Gateway with カスタム・オーソライザー」と「外部認可サーバー」による構成例API Gatewayは認可サーバーと連携し、クライアントから受け取ったアクセストークンを検証する


クライアント

WEBSITE0 7


1

2

3

4

6

5 ******

APIGateway

“カスタム・オーソライザー”（Lambda関数）

リソースサーバー

認可サーバー(e.g. Authlete, Hydra, WSO2 etc.)

認可依頼

検証依頼検証結果

ポリシー

Lambda 関数やEC2上のエンドポイント、あるい

は外部のエンドポイントへ

参考情報:http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/use-custom-authorizer.htmlhttp://qiita.com/TakahikoKawasaki/items/b372ab49da0a9aedb76ahttps://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

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は「プロトコル」ではなく「フレームワーク」。実際のサービスに適用するにはそこからいろいろな決めごとを考えていく（プロファイリングする）必要がある


リソース

サーバー

認可

サーバー

クライアント

WEBSITE0 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%2Fclient%2Eexample%2Ecom%2Fcb

HTTP/1.1Host: server.example.com

4. 認可レスポンス

HTTP/1.1 302 FoundLocation: 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




redirect_uriをどう扱うか?


決めごとの例

クライアントが認可リクエストのパラメーターとして設定する値

認可リクエストにstateパラメーターの値が設定されていた場合

認可サーバーはその値を認可レスポンスに設定する

クライアントはこの値を用いて、送信した認可リクエストと、

受信した認可レスポンスとをひもづけることができる

認可リクエストの “state” パラメーター


認可

サーバー

クライアント

WEBSITE




32







決めごとの例

仕様上(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






クライアントは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.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-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

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)」を規定

http://openid.net/wg/fapi/


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

https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md


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

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!!

https://datatracker.ietf.org/wg/oauth/documents/

http://openid.net/developers/specs/

https://tools.ietf.org/html/rfc6819

https://openid-foundation-japan.github.io/rfc6819.ja.html

https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics

https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps


[PR]☺

”APIセキュリティ” で検索していただければ幸いです

NRIセキュアの「APIセキュリティコンサルティングサービス」https://www.nri-secure.co.jp/service/consulting/apisecurity.html

https://www.nri-secure.co.jp/service/consulting/apisecurity.html

Internet

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