「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Financial API ---> Financial-grade APIと名称が変わった。
- EU決済サービス指令(Payment Services Directive/PSD)
- Open Banking Standard
を考慮し、
- ISO/TC 68(Financial services)への提出も視野に入れながら、
以下のような、金融 API の標準仕様群の策定作業が進められている。
目的 †
セキュアなOAuthプロファイルで保護されたREST / JSONデータモデルを開発することにより、
金融サービスの具体的な実装ガイドラインを提供することを目的としている。
勧告を提供する。 †
下記に関する勧告を提供(チェックリスト)
- セキュリティ+プライバシー・プロファイル
- JSON data schema, REST APIs
以下を可能にする。 †
銀行・証券口座およびクレジットカード口座を考慮対象とする。
- アプリケーションが口座を参照
- アプリケーションが口座を更新
- 利用者がセキュリティとプライバシー設定をする
背景 †
金融向けセキュリティ・プロファイルが必要 †
OAuth2.0はフレームワークなので用途に合わせたセキュリティ・プロファイルが必要。
- 基本実装でOK
- ソーシャルアプリにおけるデータ共有
- 閉回路の産業アプリケーション
金融のIdentity Federation APIの使用例 †
- 口座開設(KYCを含む)
- 個人資産管理
- 支払い、送金
- 融資申し込み
- 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)のマルウェア攻撃は、
- UserAgent?を監視し、
- ログインが成功すると、
- UserAgent?を乗っ取り、
- 情報を改ざんする。
トークンのフィッシング・リプレイ攻撃 †
- エンドポイントが変更になったなどの偽メールを流す。
- 若しくは、不正発行された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は何をしているか?
# | Message | Parameters | (a) Unique Source Identifier (ユニークなソース識別子) | (b) Protocol + version identifier (プロトコル+バージョン識別子) | (c) Full list of actor/roles (人物/役割の完全なリスト) | (d) Message Authentication (改ざんされていないメッセージ) |
1 | Authorization 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. |
2 | Authorization Response | ・code ・state ・other extension parameters | No source identifier ((レスポンス中に)ソース識別子なし。) |
3 | Token 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. |
4 | Token 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 †
- トークンの種類とセキュリティ・レベル
Part | セキュリティ・レベル | トークンの種類 | 適用 |
Part 2 | 高い | 記名式トークン (Sender Constrained Token) | 発行を受けた者しかトークンが利用できない(=飛行機のチケット) |
Part 1 | 低い | 持参人トークン (Bearer Token) | 盗難されたトークンも利用できる(=電車の切符) |
- OpenID Financial API (FAPI) WGによる対策の詳細と結果
- 整備された基準(Part 2)
# | Message | Parameters | (a) Unique Source Identifier (ユニークなソース識別子) | (b) Protocol + version identifier (プロトコル+バージョン識別子) | (c) Full list of actor/roles (人物/役割の完全なリスト) | (d) Message Authentication (改ざんされていないメッセージ) |
1 | Authorization 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 identifier | Signing by JWT Secured Authorization Request (JAR) |
2 | Authorization Response | ・code ・state ・other extension parameters | Unique redirect_uri (ユニークなredirect_uri) | (a) + client_id + state as the UA identifier / TBID as UA identifier | Signing by ID Token + s_hash |
3 | Token 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 identifier | TLS Protected |
4 | Token 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 3: Open Data API †
要約 †
詳細 †
原文読んで書く †
Part 4: Protected Data API and Schema - Read only †
要約 †
- 銀行口座
- などを参考に作成
- US FS-ISAC DDA
- OpenBank? Project
- Figo
- UK OBIEからの寄付待ち。
詳細 †
原文読んで書く †
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? †
tkudo †
勉強会 †
OAuth & OIDC 勉強会(FAPI & CIBA 特集!) †
- 『#OAuth & #OIDC 勉強会(#FAPI & #CIBA 特集)』ツイートまとめ - Togetter
<FAPI>
- Tokenエンドポイントでは
Confidential Clientの認証を義務付けている(ただし、Basic 認証は不可)。
- 共通
- redirect_uriは、完全一致にしないといけない。
- FAPI に準拠する API は、x-fapi-interaction-id HTTP ヘッダーを応答に含める。
(クライアント側のログとサーバー側のログの付き合わせを容易にするために導入された仕組み)
- リクエストに x-fapi-interaction-id HTTP ヘッダーが含まれていればその値と同じ値
- そうでなければ UUID をサーバー側で生成
<CIBA>
OSSコンソーシアム †
開発基盤部会 Blog †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth