FAPI Part 2 (Read and Write API Security Profile)

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

• Financial API (FAPI)の「Read and Write API用セキュリティ・プロファイル」
• 金融データへのトランザクション・アクセスに適したOAuthプロファイル
  • OpenID Connect（OIDC）を使用して顧客（ユーザ）を識別
  • トークンを使用して、エンドポイントから保護データを読取
  • エンドポイントは、JSONデータを提供するREST API

※ ドラフト 4 を参考にして作成。その後、ドラフト 6 を再度完読して加筆・修正。

要約 †

• 送信者・受信者・メッセージ認証を強化

• 以下の攻撃に対するコントロールを規定
  • 認可要求の改ざん
  • コードインジェクション
  • 状態インジェクション
  • トークン要求フィッシング
  • 認可応答の改ざん

フロー †

このプロファイルを簡単に説明すると、以下のようになる。

Confidentialクライアント †

• code id_token
• 共通
• 個別

Publicクライアント †

• 共通

• Native
  • code id_token（JARM）
  • 共通
  • 個別

• SPA
  • code id_token toke（Hybrid Flow）
  • 共通
  • 個別

パラメタ †

response_type †

• code id_token
  • Confidentialクライアント
  • NativeのPublicクライアントの場合、S256のOAuth PKCE

• code id_token token
  SPA系のPublicクライアントの場合
  • 8.3.3. Identity provider (IdP) mix-up attackの可能性がある。
  • 故に、Implicit Flow より Hybrid Flow

response_mode †

JARMであればHybrid Flowでなくてもいい。

request or request_uri †

• パラメタを要求。
• Requestオブジェクト

IDトークン †

JWT形式 †

• JWS署名
  • ES256（ECDSA using P-256 and SHA-256, Recommended+）
  • PS256（RSASSA-PSS using SHA-256 and MGF1 with SHA-256, Optional）

• JWE暗号化
  アルゴリズムの指定は無し。

追加クレーム †

• acrとamr
• at_hashとc_hash
• 更に、切り離された署名のためのs_hash。

切り離された署名 †

• 認可レスポンスが改ざんされていないことを検証。

• s_hash
  クライアントは、
  • at_hashとc_hashに加え、
  • s_hash

の値を検証する。

• 値
  • state 値のASCII表現のオクテットのハッシュの左端の半分をbase64urlエンコーディング
  • ハッシュはIDトークンのJOSEヘッダのalgパラメタで使用されるアルゴリズム。

• 例：algがHS512の場合
  • state値をASCIIエンコードし、
  • SHA-512でハッシュ化し、
  • 左端の256ビットを切り出し、
  • base64urlエンコードする。

• この代替に「JARM」と言う仕様もある。

通信 †

SSL/TLS †

• TLSバージョン1.2以降
• TLSサーバ証明書チェック
• 暗号スイート
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

redirect_uri †

（完全一致）

認証 †

ユーザ †

LoA 3

• 特定される⾝元識別情報の信⽤度が「相当程度ある」。
• パスワードだけではなく、2要素以上を用いてユーザー認証をする。

クライアント認証 †

• 認可エンドポイント
  Requestオブジェクト

• Tokenエンドポイント（以下の何れかが必要）
  • JWT Client Assertion（private_key_jwt）
  • 紐付け（トークン・バインディング）
    FAPIクライアントが「MTLS」または「OAUTB」を使用する場合、認証コードはTLSチャネルにバインドされます。

トークン種類 †

記名式トークン（Proof-of-possession Token）

対象 †

• code
• token
  • access_token
  • refresh_token

紐付け（トークン・バインディング） †

紐付け（トークン・バインディング）のために以下の何れかをサポートする必要がある。
（記名は、Resource Owner単位ではなくてClient単位）

• MTLS
• OAUTB

役割 †

Authorization Server †

先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。

認証・認可 †

• LoA 3

クライアント認証 †

redirect_uri †

• 事前登録が必要
• 認可リクエストに必須
• 完全一致が必要

code, token †

• 記名式トークン
  • code
  • token
    • access_token
    • refresh_token

• IDトークン

Client †

先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。

• Confidentialクライアントをサポートする。
• また、Publicクライアントをサポートすべき。

共通 †

• Requestオブジェクト

• 切り離された署名のためのs_hash

• 紐付け（トークン・バインディング）のために以下の何れかをサポートする必要がある。
  • MTLS
  • OAUTB

Confidentialクライアント †

• クライアント認証が必要。
  • Authorization Codeを使用して、
  • ＋Tokenエンドポイントにクライアント認証
    • JWT Client Assertion（private_key_jwt）
    • MTLS

• JWS & JWEのIDトークンの要求が必要推奨される。

Publicクライアント †

• SPA系は、Hybrid Flowをサポート
• Nativeは、S256のOAuth PKCEをサポート
  • 「ハッシュ関数」には、「S256」を使用する。
  • 「アプリケーション間通信」には「Claimed Https Scheme URI Redirection」を使用する。

• ＋TokenエンドポイントにOAUTBのクライアント認証が必要。

• acrクレームでLoA 3以上での認証を要求し、acrとamrを検証する。

• 各カギは、
  • SPA系は、クライアント端末ごとになる。
  • Nativeは、インストール（インスタンス）毎になる。

Resource Server †

先ずは、「FAPI Part 1 (Read Only API Security Profile)」に準拠。

記名式トークン †

• MTLS
• OAUTB

Requestオブジェクト †

Publicクライアントダケと思っていたが、Confidentialクライアントでも必要である模様。

• F-API2では、request_uriをClientではなく、Authorization Serverがホストする。

• これにより、Clientが指定したrequest_uriへの要求をサポートする必要が無い。

• Requestオブジェクトの機密性のためにURIのエントロピーに依存しない。

• request_uri形式は、以下の何れかだが、URNになるのが既定と考える。
  • URL
  • URN
    RequestオブジェクトがAuthorization Serverに保管される場合

• パラメタ
  • Requestオブジェクトには、すべてのパラメタを同梱する（※ expクレームを含める必要がある）。
  • 仕様で要求されている場合、一致した重複を更に送信しても良い。

登録リクエスト †

Request †

どうも、この（specの）コンテキストからすると、

• このリクエストは認可リクエストではなく、Requestオブジェクトの登録リクエストっぽい。
  
• また、このRequestオブジェクトの登録エンドポイントは、Discoveryで公開される。

POST https://as.example.com/ros/ HTTP/1.1
Host: as.example.com
Content-Type: application/jws
Content-Length: 1288

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiA
(... abbreviated for brevity ...)
zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

※ クライアント認証は、JWT中のissに対応した署名検証で行う。

Response †

• 正常

  HTTP/1.1 201 Created
  Date: Tue, 2 May 2017 15:22:31 GMT
  Content-Type: application/json
  
  {
      'iss':'https://as.example.com/', // AuthZのID
      'aud':'s6BhdRkqt3', // ClientID
      'request_uri':'urn:example:MTAyODAK', // urn（暗号ランダム値）
      'exp':1493738581 // 有効期限（存続期間は短く、好ましくは一回限
  }

• 異常
  • Authorization Required
    401 Unauthorized HTTP error
    署名検証が失敗した場合。

• Invalid Request
  400 Bad Request HTTP error
  Requestが無効

• Method Not Allowed
  405 Method Not Allowed HTTP error
  POST要求を使用しなかった場合

• Request Entity Too Large
  413 Request Entity Too Large HTTP error
  要求サイズが上限を超える場合。

• Too Many Requests
  429 Too Many Requests HTTP error
  ある期間にClientからの要求数が上限を超えた場合。

認可リクエスト †

request_uriをパラメタに指定して認可リクエストをおこなうダケ。

仕様（JAR → PAR） †

OAuth 2.0 Pushed Authorization Requestsが標準化されている。

• 参考
  • OAuth 2.0 Pushed Authorization Requests
    https://tools.ietf.org/id/draft-lodderstedt-oauth-par-00.html
  • 図解 PAR : OAuth 2.0 Pushed Authorization Requests - Qiita
    https://qiita.com/TakahikoKawasaki/items/97563be46b62a0e02fe6

考察 †

プロファイル †

プロファイルの識別 †

他のプロファイルの抑止 †

PublicクライアントのClient側実装 †

• Publicクライアントの場合、AuthZ実装も大変だが、Client実装が大変。
• 特に、JavaやJavaScriptでJWT検証処理等を実装する必要が出てくる。
• このためか、JWEがPublicクライアントのFlowで求められていない。

関連仕様 †

ただしOAuth2 / OIDCを除く。

FAPI Part 1 (Read Only API Security Profile) †

JWT Secured Authorization Request (JAR) †

JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) †

OAuth 2.0 Token Binding †

• MTLS: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

• OAUTB: OAuth 2.0 Token Binding

参考 †

• Financial Services – Financial API - Part 2: Read and Write API Security Profile
  http://openid.net/specs/openid-financial-api-part-2.html

  FAPI Read and Writeセキュリティ・プロファイル

• Financial API 実装の技術課題 - Qiita > FAPI Part 2
  https://qiita.com/TakahikoKawasaki/items/48a9d22205f77db59726#fapi-part-2

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth