Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,956 views

Published on

Prepared for FinTech X Security-JAWS 勉強会#01 https://atnd.org/events/88202

Published in: Internet
  • Be the first to comment

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

  1. 1. FinTech X Security-JAWS 勉強会 #01 「金融API向けOAuth」にみるOAuthプロファイリングの実際 2017-06-16 工藤達雄 http://www.linkedin.com/in/tatsuokudo Cyber Consulting Services NRI SecureTechnologies, Ltd.
  2. 2. 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を専門とする コンサルティングに従事 自己紹介
  3. 3. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 2 OpenID Foundation 配下のワーキンググループが策定を進めている 「Financial API (FAPI)」 https://openid.net/wg/fapi/ をネタに API セキュリティにおける OAuth 2.0 適用(プロファイリング)の ベストプラクティスとその先について紹介します。 本プレゼンテーションの内容
  4. 4. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 3 OAuthとは? APIアクセス(フルオープン) API サーバー APP APIクライアント HTML5 WEBSITE 1 GET /items/12345 HTTP/1.1
  5. 5. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 4 OAuthとは? APIアクセスを「クライアントのクレデンシャル」で制限する API サーバー APP APIクライアント HTML5 WEBSITE 1 ****** GET /items/12345 HTTP/1.1 x-api-key: ****** クライアントのクレデンシャルを要求
  6. 6. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 5 OAuthとは? 「クライアントのクレデンシャル」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・グラント」 リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITE 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルを 使ってトークンリクエスト ****** アクセストークンを要求 クライアントのクレデンシャルを以て アクセストークンを提供する
  7. 7. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 6 OAuthとは? リソースオーナーのID/パスワードを使ってAPIのアクセスを制限したい場合には? リソースオーナー リソース サーバー APP クライアント HTML5 WEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 1 1. ID/パスワードを 使ってAPIアクセス ユーザーID: johndoe パスワード: ****** ID/パスワードを要求
  8. 8. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 7 OAuthとは? 「リソースオーナーのID/パスワード」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・クレデンシャル・グラント」 ※非推奨 リソースオーナー リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITEWEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルと ユーザーのID/パスワードを 使ってトークンリクエスト クライアントのクレデンシャル: ****** ユーザーID: johndoe パスワード: ****** アクセストークンを要求 リソースオーナーのクレデンシャル を以てアクセストークンを提供する
  9. 9. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 8 OAuthとは? 「認可コード」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「認可コード・グラント」 リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 0. リソースへのアクセスを リクエスト 7 7. アクセストークンを 使ってAPIアクセス ユーザーエージェント 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. ユーザー認証 & クライアントへの権限委譲の確認 4 4. 認可コード提供 (ブラウザリダイレクト) 6 6. アクセストークン 提供 3 3. OK! ユーザーID: johndoe パスワード: ****** 5 5. クライアントの クレデンシャルと 認可コードを使って トークンリクエスト ****** アクセストークンを要求 認可コードを以て アクセストークンを提供する
  10. 10. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 9 「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
  11. 11. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 10 OAuthは「プロトコル」ではなく「フレームワーク」。 実際のサービスに適用するにはそこからいろいろな決めごとを考えていく(プロファイリングする)必要がある リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 1 2 3 4 6 5 認可リクエストの形式 リソースオーナーの認証・同意方法 トークンリクエスト の形式 トークンレスポンス の形式 アクセストークンの ライフサイクル アクセストークンの 利用方法 ****** クライアント 認証の方式
  12. 12. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 11 決めごとの例  クライアント側に用意する「認可コードの受け口」  クライアントは認可リクエストを認可サーバーに送信する際に redirect_uriパラメーターを用いて、どの「リダイレクション・エンド ポイント」に認可コードを送信してほしいかを指定することができる  認可サーバーはリソースオーナーとのインタラクションを行った後、 ユーザーエージェントに、「リダイレクション・エンドポイントへの リダイレクトレスポンス」として認可コードを返却する。これにより ユーザーエージェントは「リダイレクション・エンドポイント」への リクエストとして、そのパラメーターを自動的に送信することになる クライアントの「リダイレクション・エンドポイント」 リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 1. 認可リクエスト 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
  13. 13. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 12 決めごとの例  仕様上(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 ユーザー エージェント 1. 認可リクエスト 4. 認可レスポンス リダイレクション エンドポイント 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 HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=SplxlOBeZQQYbYS6WxSbIA& state=3af23asl0989gnv redirect_uriを どう扱うか?
  14. 14. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 13 決めごとの例  クライアントが認可リクエストのパラメーターとして設定する値  認可リクエストにstateパラメーターの値が設定されていた場合 認可サーバーはその値を認可レスポンスに設定する  クライアントはこの値を用いて、送信した認可リクエストと、 受信した認可レスポンスとをひもづけることができる 認可リクエストの “state” パラメーター リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 1. 認可リクエスト 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
  15. 15. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 14 決めごとの例  仕様上(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 1. 認可リクエスト 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 クライアントは stateの値を どう作るか?
  16. 16. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 15 決めごとの例  仕様上 (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 Host: server.example.com 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) で良い?
  17. 17. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 16 金融分野のAPIにおけるOAuthの「詳細仕様の標準化」 → プロファイルの標準化 が期待されてる(んだと思う) オープンAPIのあり方に関する検討会報告書-オープン・イノベーションの活性化に向けて-【中間的な整理(案)】 https://www.zenginkyo.or.jp/fileadmin/res/news/news290316_2.pdf
  18. 18. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 17 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)」を規定
  19. 19. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 18 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の利用)
  20. 20. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 19 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
  21. 21. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 20 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
  22. 22. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 21 OAuth を活用してAPIアクセス認可を実現する ためには「プロファイリング」が必要です 金融向けAPIはもとより、それに限らず一般的 にOAuthのプロファイリングを行う際には、 OpenID Foundation の Financial API WG が 策定を進めている仕様群は要チェックです まとめ
  23. 23. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 22  使える「車輪」や「車輪の部品」はたくさんある  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!!
  24. 24. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 23 [PR]☺  ”APIセキュリティ” で検索していただければ幸いです NRIセキュアの 「APIセキュリティコンサルティングサービス」 https://www.nri-secure.co.jp/service/consulting/apisecurity.html

×