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

目次

概要

Financial API ---> Financial-grade APIと名称が変わった。

  • EU決済サービス指令(Payment Services Directive/PSD)
  • Open Banking Standard

を考慮し、

  • ISO/TC 68(Financial services)への提出も視野に入れながら、

以下のような、金融 API の標準仕様群の策定作業が進められている。

PartTitle説明
1Read Only API Security Profile参照系 API(向けの)セキュリティー要件
2Read & Write API Security Profile更新系 API(向けの)セキュリティー要件
3Open Data API公開データ API 仕様
4Protected Data API and Schema - Read only参照系 API(向けの)仕様
5Protected Data API and Schema - Read and Write更新系 API(向けの)仕様

目的

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

勧告を提供する。

下記に関する勧告を提供(チェックリスト)

  • セキュリティ+プライバシー・プロファイル
  • JSON data schema, REST APIs

以下を可能にする。

銀行・証券口座およびクレジットカード口座を考慮対象とする。

  • アプリケーションが口座を参照
  • アプリケーションが口座を更新
  • 利用者がセキュリティとプライバシー設定をする

背景

金融向けセキュリティ・プロファイルが必要

OAuth2.0はフレームワークなので用途に合わせたセキュリティ・プロファイルが必要。

  • 基本実装でOK
    • ソーシャルアプリにおけるデータ共有
    • 閉回路の産業アプリケーション

金融のIdentity Federation APIの使用例

  1. 口座開設(KYCを含む)
  2. 個人資産管理
  3. 支払い、送金
  4. 融資申し込み
  5. AIによるポートフォリオ管理(出所)

様々な団体からの後押し

  • INDUSTRY PUSH
    • FS-ISAC(Financial Services - Information Sharing and Analysis Center)
      の定める継続的データAPI(Durable Data API)に関する委員会。
    • (Source) FS-ISAC FSDDA WG OpenID Financial API
  • REGULATORY PUSH
    • EU決済サービス指令(Payment Services Directive/PSD)2017年末までにAPIの可用性を要求。
    • (Source) ODI OBWG: The Open Banking Standard (2016) JSON REST OAuth OpenID Connect
  • Regulatory Pressures (規制圧力)
    • リリース1 - 12ヶ月以内に完了させる。
      密接に範囲を絞ったOpen Banking APIのローンチにより、
      オープンなデータのselect, read-accessの使用が可能になった。
  • リリース2 - 2017年第1四半期までに完成させる。
    midata(第三者の個人顧客データ)への読み取りアクセス(読み取り専用)
  • リリース3 - 2018年第1四半期までに完成させる。
    midata(第三者の企業顧客データ)への読み取りアクセス(読み取り専用)
  • リリース4 - 2019年1月末までに完了する
    • 高リスク - 完全な読み書きアクセス。
    • 最小midataはcsvファイル。

考慮事項

金融機関API向けのプロファイルは 全てを解決する必要がある。

1 Client・1 Authorization Server

  • 1 Clientは、 1 Authorization Serverとのみ関係を持つ。
    (リダイレクト・エンドポイントを分け、クライアントの論理分割)
  • 個人財務管理ソフトウェア/クライアントの場合、
    • 複数のAuthorization Serverが必然的に必要。
    • バーチャル・セパレーションを行う。
      Authorization Server毎に異なるRedirectエンドポイントを設ける。

メッセージに関する各種の認証

  • UserAgent?(ブラウザなど)を介した通信は、UserAgent?がTLS終端になり、保護されない。
  • メッセージは変更される恐れがあり、また、メッセージは汚染チェックされずに使われることが多い。
  • このため、FAPIでは、メッセージに関する各種の認証を必要としている。

メッセージの種類

  • 認可リクエスト
    • 送信者:Client
    • 受信者:Authorization Server
  • 認可レスポンス
    • 送信者:Authorization Server
    • 受信者:Client
  • アクセストークン・リクエスト
    • 送信者:Client
    • 受信者:Authorization Server
  • アクセストークン・レスポンス
    • 送信者:Authorization Server
    • 受信者:Client

メッセージ自体の認証

各種リクエスト・レスポンスの各種パラメタが改ざんされないようにする必要がある。

メッセージ送信者の認証

  • Redirectで中継する、メッセージの送信元の認証

メッセージ受信者の認証

  • Redirectで中継する、メッセージの受信先の認証
  • 特にスマホ端末では、以下に対する注意が必要になる。
    • Publicクライアントによる「Accessトークン横取り攻撃」
    • Private-Use URL Scheme上書きによる「認可コード横取り攻撃」

ユーザーIDと認証の問題

  • 利用者(Resource Owner)のIDの概念がない。
  • ユーザー認証は「範囲外」です。

メッセージ機密性の問題

  • UserAgent?がTLS終端であるが、
    アプリケーション層で暗号化されていないため、
    UserAgent?上でメッセージを見ることができる。
  • MITB(Man in the Browser)のマルウェア攻撃は、
    1. UserAgent?を監視し、
    2. ログインが成功すると、
    3. UserAgent?を乗っ取り、
    4. 情報を改ざんする。

トークンのフィッシング・リプレイ攻撃

  • エンドポイントが変更になったなどの偽メールを流す。
  • Authorization Server
    • 認可リクエスト
    • アクセストークン・リクエスト
  • Resource Server
    • リソースのリクエスト
  • 若しくは、不正発行されたTLS 証明書とDNS スプーフィングの組み合わせ。

機能

基準

(a) Unique Source Identifier(ユニークなソース識別子

各種のソース識別子(IF)が一意(ユニーク)。

  • Resource Owner
  • Authorization Server
  • Resource Server

(b) Protocol + version identifier(プロトコル + バージョン + msg識別子

プロトコル + バージョン + msg識別子などが明確に決められている。

(c) Full list of actor/roles(人物/役割の完全なリスト

(d) Message Authentication(改ざんされていないメッセージ

メッセージ自体の認証による、改ざんされていないメッセージの実現。

AS-IS / TO-BE

AS-IS

  • RFC6749は何をしているか?
    #MessageParameters(a) Unique Source Identifier
    (ユニークなソース識別子)
    (b) Protocol + version identifier
    (プロトコル+バージョン識別子)
    (c) Full list of actor/roles
    (人物/役割の完全なリスト)
    (d) Message Authentication
    (改ざんされていないメッセージ)
    1Authorization Request・response_type
    ・client_id
    ・redirect_uri
    ・scope
    ・state
    Client ID is not globally unique.
    Tampering possible.
    (client_idはグローバルに一意ではありません。
    改ざん可能です。)
    OK,
    but it is not integrity protected.
    (しかし、それは完全性保護されていません。)
    No.No.
    2Authorization Response・code
    ・state
    ・other extension parameters
    No source identifier
    ((レスポンス中に)ソース識別子なし。)
    3Token Request・grant_type
    ・code
    ・redirect uri
    ・client_id/client_secret
    Client ID is not globally unique.
    Tampering possible.
    (client_idはグローバルに一意ではありません。
    改ざん可能です。)
    OK
    (as long as there is no OAuth 3.0)
    (OAuth 3.0が存在しない限り)
    No.OK.
    4Token Response・access_token
    ・token_type
    ・expires_in
    ・refresh_token others
    No source identifier
    ((レスポンス中に)ソース識別子なし。)
  • RFC6749の認証への対応状況
    #メッセージメッセージ送信者の認証メッセージ受信者の認証メッセージ自体の認証
    1認可リクエストIndirect(間接)None(なし)None(なし)
    2認可レスポンスNone(なし)None(なし)None(なし)
    3アクセストークン・リクエストWeak(弱い)Good(良い)Good(良い)
    4アクセストークン・レスポンスGood(良い)Good(良い)Good(良い)

TO-BE

  • OpenID Financial API (FAPI) WGによる対策
    • 認証要求・応答の種類とセキュリティ・レベル
      Partセキュリティ・レベル機能セット適用
      Part 2高いJWS Authz Req w / Hybrid Flow認可リクエストの保護
      強化されたクライアント認証
      Hybrid Flow (秘密のクライアント)
      stateインジェクションの回避のために、‘s_hash’ を含む。
      認可レスポンスの保護
      Part 1Code Flow (秘密のクライアント) + PKCE + MTLS・code injectionへの対応
      ・長期Bearer Tokenの排除
      -Code Flow (秘密のクライアント)クライアント認証有り
      -Implicit Flowクライアント認証無し
      -低いPlain OAuthAnonymous
  • トークンの種類とセキュリティ・レベル
    Partセキュリティ・レベルトークンの種類適用
    Part 2高い記名式トークン (Sender Constrained Token)発行を受けた者しかトークンが利用できない(=飛行機のチケット)
    Part 1低い持参人トークン (Bearer Token)盗難されたトークンも利用できる(=電車の切符)
  • OpenID Financial API (FAPI) WGによる対策の詳細と結果
    • 整備された基準(Part 2
      #MessageParameters(a) Unique Source Identifier
      (ユニークなソース識別子)
      (b) Protocol + version identifier
      (プロトコル+バージョン識別子)
      (c) Full list of actor/roles
      (人物/役割の完全なリスト)
      (d) Message Authentication
      (改ざんされていないメッセージ)
      1Authorization Request・response_type
      ・client_id
      ・redirect_uri
      ・scope
      ・state
      Unique redirect_uri + client_id
      (ユニークなredirect_uriとclient_id)
      OK (Unique Parameter List)
      (多分、決められていることを意味している)
      (a) + state as the UA identifier / TBID as UA identifierSigning by JWT Secured Authorization Request (JAR)
      2Authorization Response・code
      ・state
      ・other extension parameters
      Unique redirect_uri
      (ユニークなredirect_uri)
      (a) + client_id + state as the UA identifier / TBID as UA identifierSigning by ID Token + s_hash
      3Token Request・grant_type
      ・code
      ・redirect_uri
      ・client_id/client_secret
      Unique redirect_uri + client_id
      (ユニークなredirect_uriとclient_id)
      OK (Unique Parameter List)
      (多分、決められていることを意味している)
      (a) + state as the UA identifier / TBID as UA identifierTLS Protected
      4Token Response・access_token
      ・token_type
      ・expires_in
      ・refresh_token
      ・others
      redirect_uri(a) + client_id + state as the UA identifier / TBID as UA identifier

Part

現在Part1, 2がImplementer's Draftであり安定した仕様で、
実装を始めても問題のない状態状態になっている。

Part 1: Read Only API Security Profile

Part 2: Read and Write API Security Profile

Part X: Client Initiated Backchannel Authentication Profile

要約

UK OBIE(Open Banking Implementation Entity)からの寄付待ち。

詳細

原文読んで書く

Part 3: Open Data API

要約

詳細

原文読んで書く

Part 4: Protected Data API and Schema - Read only

要約

  • 銀行口座
    • などを参考に作成
      • US FS-ISAC DDA
      • OpenBank? Project
      • Figo
    • UK OBIEからの寄付待ち。
  • 証券口座
    現在NRIで試案作成中

詳細

原文読んで書く

Part 5: Protected Data API and Schema - Read and Write

要約

  • 同上
  • Scopeではなく、Claims Requestを使うことで、より詳細・柔軟な認可を取得。

詳細

原文読んで書く

参考

OpenID

OpenID Financial API (FAPI) WG

NRI、Microsoft、Intuitが中心となり組織されたWG。

OpenID Certification | OpenID

http://openid.net/certification/

  • 仕様が正しく実装されているかどうか確認できる。
  • オンライン提供されているテスト・スイートを使う。
  • 結果をSelf Certify して登録・公開
    → FTC法5条の配下に入る。これによって信頼性を担保。
  • ログも公開されるので、虚偽の申告は、他者が指摘可能。
  • 現在はOP Certification, RP Certificationが正式提供中。
  • FAPIにおいても、同様のスキームでテスト可能にする予定。

インフル的な

nat

TakahikoKawasaki?

その他


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-28 (日) 17:26:36 (50d)