Financial API - Part 1

Last updated 2 months ago

Financial API - Part 1: Read-Only API Security Profile 和訳例

はじめに

本和訳は個人で作成・公開している、あくまで例であり、意訳や間違いが含まれておりますことをご了承ください。

コメントや誤り指摘等は、Twitter @sami_mkw_ までいただけますと幸いですm(_ _)m

Financial API - Part 1: Read-Only API Security Profile

http://openid.net/specs/openid-financial-api-part-1.html

Warning

省略

Copyright Notice & License

省略

序文 (Foreword)

OpenID Foundation(OIDF)は,OpenIDコミュニティとテクノロジーを促進,保護,育成する.非営利国際標準化団体として,160を超える参加企業(ワークグループ参加者)によって構成されているimplementer drafts および,最終的な国際標準を作成する作業は,OpenIDプロセスに従ってOIDFワークグループを通じて行われる.ワークグループの目的に関心のある人は,そのワークグループに参加する権利がある.OIDFと連携している政府機関および非政府組織もこの作業に参加している.OIDFは関連分野の他の標準化機関と密接に協力している.

Financial APIは,以下の各パートにより構成されている.

  • パート1:読み取り専用APIのセキュリティプロファイル

  • パート2:読み取り&書き込みAPIのセキュリティプロファイル

  • パート3:オープンデータAPI

  • パート4:データにアクセスするためのAPIとスキーマ - 読み取り専用

  • パート5:データにアクセスするためのAPIとスキーマ - 読み取りと書き込み

これらは,[RFC6749],[RFC6750],[RFC7636],および[OIDC]と共に使用されることを意図している.

導入(Introduction)

Fintechは,世界中の将来の経済成長の領域であり,Fintechは,業務のセキュリティを強化し,顧客データを保護する必要がある.たとえば,データをキャプチャしてユーザー名やパスワードなどの別のサービスに変換する方法として,スクリーンスクレイピングが数十年に及び共通的なアグリゲーションサービスとして利用されている.しかしこれによって,アプリケーションに対して自動化された攻撃を許容し,アグリゲータのホワイトリストを維持することを金融機関に要求するというセキュリティギャップが生み出される.このワークグループによって提案された新しいドラフト標準は,OAuth [RFC6749,RFC6750]のような,構造化されたデータとトークンモデルを持つAPIモデルを利用する.

Financial APIは,セキュアなOAuthプロファイルで保護されたREST / JSONデータモデルを開発することにより,オンラインバンキングのユースケースを採用する金融サービスの具体的な実装ガイドラインを提供することを目的としている.

本ドキュメントは,5つのパートから成る Financial API のパート1であり,読み取り専用金融データのアクセスに使用するのに適したOAuthのプロファイルを提供する.

読み取り&書き込みAPIに適した,より高いレベルのセキュリティプロファイルがパート2で提供され,パート 3 / 4 / 5 は特定のユースケース用のデータスキーマを提供する.

Notational Conventions

(略)

1. スコープ

本ドキュメントでは,アプリケーションにおける下記についての手段を記述する.

  • Financial データの読み取り専用OAuthトークンを安全に入手する

  • OpenID Connect(OIDC)を使用して顧客(ユーザ)を識別する

  • トークンを使用し,RESTエンドポイントからFinancialデータを読み取る

2. Normative References

以下の参考文献について,本書と併せて使用することを強く推奨する.日付の付されているものは,引用した版のみ適用, そうでないものは最新版(改訂を含む)が適用される.

  • [RFC7230] - Hypertext Transfer Protocol -- HTTP/1.1

  • [RFC4122] A Universally Unique IDentifier (UUID) URN Namespace

  • [RFC6749] - The OAuth 2.0 Authorization Framework

  • [RFC6750] - The OAuth 2.0 Authorization Framework: Bearer Token Usage

  • [RFC7636] - Proof Key for Code Exchange by OAuth Public Clients

  • [RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2

  • [RFC7525] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

  • [RFC6125] - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

  • [O2fNA] - OAuth 2.0 for Native Apps(和訳版はこちら

  • [RFC6819] - OAuth 2.0 Threat Model and Security Considerations

  • [OIDC] - OpenID Connect Core 1.0 incorporating errata set 1

  • [OIDD] - OpenID Connect Discovery 1.0 incorporating errata set 1

  • [OIDM] - OAuth 2.0 Multiple Response Type Encoding Practices

  • [X.1254] - Entity Authentication Assurance Framework

  • [MTLS] - Mutual TLS Profile for OAuth 2.0

3. 用語定義

本書では,[RFC6749],[RFC6750],[RFC7636],[OpenID Connect Core] [OIDC]で定義されている用語を適用する.

4. 記号と略語

  • API – Application Programming Interface

  • CSRF - Cross Site Request Forgery

  • FAPI - Financial API

  • FI – Financial Institution

  • HTTP – Hyper Text Transfer Protocol

  • REST – Representational State Transfer

  • TLS – Transport Layer Security

5. Read-Only API Security Profile

5.1. 導入(Introduction)

OIDF Financial API(FAPI)は,アカウントおよびトランザクションに関連するデータを表すJSONデータを提供するREST APIである.これらのAPIは,[RFC6749],[RFC6750],[RFC7636],およびその他の仕様で構成されるOAuth 2.0認可フレームワークによって保護されている.

読み取り専用アクセスは一般的に書き込みアクセスよりもリスクが低いとみなされ,トークンに必要な特性と,トークンを取得する方法が別々に説明される.

5.2. Read-Only API Security Provisions

5.2.1. 導入(Introduction)

読み取り専用アクセスは,書き込みアクセスと比較してリスクが低いシナリオである.したがって,セキュリティレベルも低くすることができる.しかし,FAPIでは潜在的に機密情報を提供することができるため,基本的な[RFC6749]の要求よりも高いレベルのセキュリティが必要である.

OAuth 2.0認可フレームワークのプロファイルとして,本書では,FAPIの読み取り専用APIに対して以下を要求する.

5.2.2. 認可サーバ(Authorization Server)

認可サーバは,

  1. confidential clientsをサポートする(SHALL)

  2. public clientsをサポートする(SHOULD)

  3. 対称鍵を使用する場合,[OIDC]の16.19章の要件に準拠したclient secretを提供する(SHALL)

  4. confidential clientはTokenエンドポイントにおいて,次の方法を利用して認証される(SHALL)

    1. TLS 相互認証 [MTLS]

    2. [OIDC]の9章で指定されたclient_secretまたは秘密鍵を使用したJWSクライアントアサーション

  5. クライアント認証にRSAアルゴリズムが使われる場合は,2048 bit かそれ以上の鍵長を必要とする(SHALL)

  6. クライアント認証に楕円曲線アルゴリズム使われる場合は,160bit かそれ以上の鍵長を必要とする(SHALL)

  7. public clientをサポートする場合,code challenge method がS256である [RFC7636] をサポートする(SHALL)

  8. Redirect URI を事前登録しなければならない(SHALL)

  9. 認可リクエストにredirect_uriパラメータを含まなければならない(SHALL)

  10. redirect_uriの値が,事前登録済みのRedirect URIのうちのいずれかに完全一致しなければならない(SHALL)

  11. [X.1254]で定義されているLoA2以上のユーザ認証を要する(SHALL)

  12. 要求されたscopeが事前認可されたものでなければ,明示的にユーザに同意を取る必要がある(SHALL)

  13. 可能であれば,認可コード([RFC6749]の1.3.1項)が以前に利用済のものでないことを検証する(SHALL)

  14. [RFC6749]の4.1.4項に従うトークン応答を返却する(SHALL)

  15. 発行したアクセストークンで許可されているスコープのリストを返却しなければならない(SHALL)

  16. [RFC6819]の5.1.4.2.2項で定義されているように,最小128ビットの不明瞭で推測不可能なアクセストークンを提供する(SHALL)

  17. [OIDC]の16.18の通り,長期的な同意を取得する場合,ユーザ認可中に明確に特定する必要がある(SHALL)

  18. そして,[OIDC]の16.18の通り,クライアントに付与されたアクセストークンとリフレッシュトークンをエントユーザが無効化する仕組みを提供する必要がある(SHALL) 注:Financial APIサーバは,特定のAPIを実装しないため,スコープを制限することがある.

    注:[RFC6749]の4.1.3節はcode reuseに関する指針を規定していないが,本文書は[OIDC]3.1.3.2節でのcode reuseの制限を規定している.

    注:認可コードがリプレイされているか否かを識別できない場合は,認可コードの有効期間を1分もしくは適切に短い期間に設定することが望ましい.有効期間は,認可コードが使用済みの場合,その認可コードキャッシュをクリアするタイミング制御のインジケータとして機能する.

    注:アクセストークンを不明瞭にする要件は,サーバが構造化されたアクセストークンを作成することを妨ぐものではない.

    さらに,認証されたユーザの識別子をトークンレスポンスでクライアントに提供することが望ましい場合,認証サーバは,

  19. [OIDC]3.1.2.1項の通り,認証要求をサポートする(SHALL)

  20. [OIDC]3.1.2.2項の通り,認証要求の検証を実施する(SHALL)

  21. [OIDC]3.1.2.2項および3.1.2.3項の通りユーザを認証する(SHALL)

  22. 認証の結果に応じて[OIDC]3.1.2.4項および3.1.2.5項の通り認証応答を提供する(SHALL)

  23. [OIDC]3.1.3.2項の通りトークン要求の検証を行う(SHALL)

  24. そして,[OIDC]3.1.3.3項の通り,要求されたscopeopenidが含まれていれば,トークンレスポンスに,認証したユーザに関するsubの値とオプションでacrの値を含むIDトークンを発行する(SHALL)

5.2.3. Public Client

Public Clientは,

  1. [RFC7636]またはFinancial APIで定義されたメカニズム Financial API - Part 2 をサポートする(SHALL)

  2. [RFC7636] の code challenge method として S256を使う(SHALL)

  3. 利用する認可サーバ毎に独立した異なるRedirect URI を使う(SHALL)

  4. Redirect URI の値をリソースオーナーのユーザエージェント(ブラウザなど)のセッションに格納し,認可レスポンスを受信したRedirect URIと比較する.URIが一致しない場合,クライアントはエラーとしてプロセスを終了する(SHALL)

  5. [O2fNA]が示しているベストプラクティスを遵守する(SHALL)

  6. そして,効果的なCSRF対策を実装する(SHALL) さらに,認証ユーザの永続識別子を取得する場合には,

  7. scope の値に openid を含める(SHALL)

  8. そして,[OIDC]の3.1.2.1項で定義された認証要求に nonce パラメータを含む(SHALL) 注記:[RFC7636]への準拠は,トークン要求にcode_verifierパラメータが含まれていることを意味する.

5.2.4. Confidential Client

[RFC7636]のサポートを除いたPublic Clientの規定に加え,Confidential Clientは,

  1. トークンエンドポイントで認証する方法として下記をサポートする(SHALL)

    1. TLS相互認証 [MTLS] または,

    2. [OIDC]の9章で指定されたclient_secretまたは秘密鍵を使用したJWSクライアントアサーション

  2. RSA暗号が使われる場合は,少なくとも 2048 bit の鍵長を必要とする(SHALL)

  3. 楕円曲線暗号が使われる場合は,少なくとも 160bit の鍵長を必要とする(SHALL)

  4. 共通鍵暗号が使われる場合は,クライアントの秘密鍵が少なくとも 128bit であることを検証しなければならない.