「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>OpenID / OAuth / OpenID Connect]]
-戻る
--[[OAuth 2.0 拡張]]
--[[OpenID / OAuth / OpenID Connect]]

* 目次 [#m9a7ace2]
#contents

*概要 [#c3d7eaf3]
Financial API ---> Financial-grade APIと名称が変わった。

-[[OpenID Financial API (FAPI) WG>#f4f721ee]]において、

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

を考慮し、
-ISO/TC 68(Financial services)への提出も視野に入れながら、

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

|Part|Title|説明|h
|1|[[Read Only API Security Profile>#jcbf3a32]]|参照系 API(向けの)セキュリティー要件|
|2|[[Read & Write API Security Profile>#j5efef5b]]|更新系 API(向けの)セキュリティー要件|
|3|[[Open Data API>#x600e47c]]|公開データ API 仕様|
|4|[[Protected Data API and Schema - Read only>#ve2809ce]]|参照系 API(向けの)仕様|
|5|[[Protected Data API and Schema - Read and Write>#o9625781]]|更新系 API(向けの)仕様|

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

***勧告を提供する。 [#wfe4b9ec]
下記に関する勧告を提供(チェックリスト)
-セキュリティ+プライバシー・プロファイル
-JSON data schema, REST APIs

***以下を可能にする。 [#v208b39c]
銀行・証券口座およびクレジットカード口座を考慮対象とする。
-アプリケーションが口座を参照
-アプリケーションが口座を更新
-利用者がセキュリティとプライバシー設定をする

**背景 [#eda6649b]
***金融向けセキュリティ・プロファイルが必要 [#gf05d567]
OAuth2.0はフレームワークなので用途に合わせたセキュリティ・プロファイルが必要。

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

-金融機関APIのセキュリティ・プロファイル
--[[Read Only API用セキュリティ・プロファイル>#jcbf3a32]]
--[[Read and Write API用セキュリティ・プロファイル>#j5efef5b]]

***金融のIdentity Federation APIの使用例 [#k79735dc]

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

***様々な団体からの後押し [#geb3e8d1]
-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ファイル。 

*考慮事項 [#g964b656]
金融機関API向けのプロファイルは 全てを解決する必要がある。

**1 Client・1 Authorization Server [#t12a7cab]
-1 Clientは、 1 Authorization Serverとのみ関係を持つ。~
(リダイレクト・エンドポイントを分け、クライアントの論理分割)

-個人財務管理ソフトウェア/クライアントの場合、
--複数のAuthorization Serverが必然的に必要。
--バーチャル・セパレーションを行う。~
Authorization Server毎に異なるRedirectエンドポイントを設ける。

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

***メッセージの種類 [#hd5c59a6]
-認可リクエスト
--送信者:Client
--受信者:Authorization Server

-認可レスポンス
--送信者:Authorization Server
--受信者:Client

-アクセストークン・リクエスト
--送信者:Client
--受信者:Authorization Server

-アクセストークン・レスポンス
--送信者:Authorization Server
--受信者:Client

***メッセージ自体の認証 [#rbe12d2b]
各種リクエスト・レスポンスの各種パラメタが改ざんされないようにする必要がある。

***メッセージ送信者の認証 [#s130153f]
-Redirectで中継する、メッセージの送信元の認証

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

**ユーザーIDと認証の問題 [#i918c34c]
-利用者(Resource Owner)のIDの概念がない。
-ユーザー認証は「範囲外」です。

**メッセージ機密性の問題 [#ga03fb1d]
-UserAgentがTLS終端であるが、~
アプリケーション層で暗号化されていないため、~
UserAgent上でメッセージを見ることができる。

-MITB(Man in the Browser)のマルウェア攻撃は、
>
+UserAgentを監視し、
+ログインが成功すると、
+UserAgentを乗っ取り、
+情報を改ざんする。

**トークンのフィッシング・リプレイ攻撃 [#eff1779a]
-エンドポイントが変更になったなどの偽メールを流す。

--Authorization Server
---認可リクエスト
---アクセストークン・リクエスト

--Resource Server
---リソースのリクエスト

-若しくは、不正発行されたTLS 証明書とDNS スプーフィングの組み合わせ。

*機能 [#yaefe264]

**基準 [#o2f057e2]

***(a) Unique Source Identifier(ユニークなソース識別子 [#m3a6c087]
各種のソース識別子(IF)が一意(ユニーク)。
-Resource Owner
-Authorization Server
-Resource Server

***(b) Protocol + version identifier(プロトコル + バージョン + msg識別子 [#k1f97233]
プロトコル + バージョン + msg識別子などが明確に決められている。

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

***(d) Message Authentication(改ざんされていないメッセージ [#i644ba08]
メッセージ自体の認証による、改ざんされていないメッセージの実現。

**AS-IS / TO-BE [#e39021f0]

***AS-IS [#n6c15b3c]

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

-RFC6749の認証への対応状況
|#|メッセージ|メッセージ送信者の認証|メッセージ受信者の認証|メッセージ自体の認証|h
|1|認可リクエスト|Indirect(間接)|None(なし)|None(なし)|
|2|認可レスポンス|None(なし)|None(なし)|None(なし)|
|3|アクセストークン・リクエスト|Weak(弱い)|Good(良い)|Good(良い)|
|4|アクセストークン・レスポンス|Good(良い)|Good(良い)|Good(良い)|

***TO-BE [#t5c59f1e]
-[[OpenID Financial API (FAPI) WG>#f4f721ee]]による対策
--認証要求・応答の種類とセキュリティ・レベル
|Part|セキュリティ・レベル|機能セット|適用|h
|[[Part 2>#j5efef5b]]|高い|[[JWS Authz Req w>OpenID Connect#m6d72953]] / [[Hybrid Flow>OpenID Connect#l565139a]]|認可リクエストの保護&br;強化されたクライアント認証|
|[[Part 2>#j5efef5b]]|高い|[[JWS Authz Req w>OpenID Connect#q19eeb33]] / [[Hybrid Flow>OpenID Connect#l565139a]]|認可リクエストの保護&br;強化されたクライアント認証|
|~||[[Hybrid Flow>OpenID Connect#l565139a]] (秘密のクライアント)&br;stateインジェクションの回避のために、‘[[s_hash>FAPI Part 2 (Read and Write API Security Profile)#k722ecb6]]’ を含む。|認可レスポンスの保護|
|[[Part 1>#jcbf3a32]]||[[Code Flow>OAuth#yfeb403d]] (秘密のクライアント) + [[PKCE>OAuth PKCE]] + MTLS|・code injectionへの対応&br;・長期Bearer Tokenの排除|
|-||[[Code Flow>OAuth#yfeb403d]] (秘密のクライアント)|クライアント認証有り|
|-||[[Implicit Flow>OAuth#m5c2d510]]|クライアント認証無し|
|-|低い|[[Plain OAuth>OAuth]]|Anonymous|

--トークンの種類とセキュリティ・レベル
|Part|セキュリティ・レベル|トークンの種類|適用|h
|[[Part 2>#j5efef5b]]|高い|記名式トークン (Sender Constrained Token)|発行を受けた者しかトークンが利用できない(=飛行機のチケット)|
|[[Part 1>#jcbf3a32]]|低い|持参人トークン (Bearer Token)|盗難されたトークンも利用できる(=電車の切符)|

-[[OpenID Financial API (FAPI) WG>#f4f721ee]]による対策の詳細と結果
--整備された基準([[Part 2>#j5efef5b]])
|#|Message|Parameters|(a) Unique Source Identifier&br;(ユニークなソース識別子)|(b) Protocol + version identifier&br;(プロトコル+バージョン識別子)|(c) Full list of actor/roles&br;(人物/役割の完全なリスト)|(d) Message Authentication&br;(改ざんされていないメッセージ)|h
|1|Authorization Request|・response_type&br;・client_id&br;・redirect_uri&br;・scope&br;・state|Unique redirect_uri + client_id&br;(ユニークなredirect_uriとclient_id)|OK (Unique Parameter List)&br;(多分、決められていることを意味している)|(a) + state as the UA identifier / TBID as UA identifier|Signing by [[JWT Secured Authorization Request (JAR)>#a0c1344d]]|
|1|Authorization Request|・response_type&br;・client_id&br;・redirect_uri&br;・scope&br;・state|Unique redirect_uri + client_id&br;(ユニークなredirect_uriとclient_id)|OK (Unique Parameter List)&br;(多分、決められていることを意味している)|(a) + state as the UA identifier / TBID as UA identifier|Signing by [[JWT Secured Authorization Request (JAR)>OpenID Connect#q19eeb33]]|
|2|Authorization Response|・code&br;・state&br;・other extension parameters|Unique redirect_uri&br;(ユニークなredirect_uri)|~|(a) + client_id + state as the UA identifier / TBID as UA identifier |[[Signing by ID Token>OpenID Connect#ofb73c59]] + [[s_hash>FAPI Part 2 (Read and Write API Security Profile)#k722ecb6]]|
|3|Token Request|・grant_type&br;・code&br;・redirect_uri&br;・client_id/client_secret|Unique redirect_uri + client_id&br;(ユニークなredirect_uriとclient_id)|OK (Unique Parameter List)&br;(多分、決められていることを意味している)|(a) + state as the UA identifier / TBID as UA identifier|TLS Protected|
|4|Token Response|・access_token&br;・token_type&br;・expires_in&br;・refresh_token&br;・others|redirect_uri|~|(a) + client_id + state as the UA identifier / TBID as UA identifier|~|

--メッセージの認証状況([[Part 2>#j5efef5b]])
|#|メッセージ|送信者認証|受信者認証|メッセージ認証|h
|1|認可リクエスト|[[Request Object>OpenID Connect#m6d72953]]|[[Request Object>OpenID Connect#m6d72953]]|[[Request object>OpenID Connect#m6d72953]]|
|1|認可リクエスト|[[Request Object>OpenID Connect#q19eeb33]]|[[Request Object>OpenID Connect#q19eeb33]]|[[Request object>OpenID Connect#q19eeb33]]|
|2|認可レスポンス|[[Hybrid Flow>OpenID Connect#l565139a]]|[[Hybrid Flow>OpenID Connect#l565139a]]|[[Hybrid Flow>OpenID Connect#l565139a]]|
|3|アクセストークン・リクエスト|Good|Good|Good|
|4|アクセストークン・レスポンス|Good|Good|Good|

*仕様 [#g2ce933d]

*Part [#g2ce933d]
現在[[Part1>#jcbf3a32]], [[2>#j5efef5b]]がImplementer's Draftであり安定した仕様で、~
実装を始めても問題のない状態状態になっている。
 
**[[Part 1: Read Only API Security Profile>FAPI Part 1 (Read Only API Security Profile)]] [#jcbf3a32]

**[[Part 2: Read and Write API Security Profile>FAPI Part 2 (Read and Write API Security Profile)]] [#j5efef5b]

**Part X: Client Initiated Backchannel Authentication Profile [#xdbf7e2a]
**Part X: [[Client Initiated Backchannel Authentication Profile>CIBA(Client Initiated Backchannel Authentication)#fc870e7d]] [#xdbf7e2a]

***要約 [#beca2e75]
UK OBIE(Open Banking Implementation Entity)からの寄付待ち。

***詳細 [#f5db4a5d]
***原文読んで書く [#ie73e565]

**Part 3: Open Data API [#x600e47c]

***要約 [#c69533aa]
***詳細 [#i755f34d]
***原文読んで書く [#vb084c7e]

**Part 4: Protected Data API and Schema - Read only [#ve2809ce]

***要約 [#qb4c7fe9]
-銀行口座~
--などを参考に作成
---US FS-ISAC DDA
---OpenBank Project
---Figo
--UK OBIEからの寄付待ち。

-証券口座~
現在NRIで試案作成中

***詳細 [#w547b2fa]
***原文読んで書く [#je445c7d]

**Part 5: Protected Data API and Schema - Read and Write [#o9625781]
***要約 [#s063c7fc]
-同上
-Scopeではなく、Claims Requestを使うことで、より詳細・柔軟な認可を取得。

***詳細 [#n28beb52]

***原文読んで書く [#s6e83d89]

*関連仕様 [#l4147461]
*参考 [#rb6016fa]

**クライアント認証 [#v874c853]
-Financial-grade APIについて — HACK The Nikkei~
https://hack.nikkei.com/blog/fapi_and_conformance_test/

***[[OAuth 2.0 Mutual TLS]] [#l97e2e37]

***[[OAuth 2.0 Token Binding]] [#h9e26456]

**メッセージ認証 [#m6997b05]
***[[JWT Secured Authorization Request (JAR)]] [#a0c1344d]

**ユーザ認証 [#tc229f3f]
***LoA 認定プログラム [#h48691d5]
-学認 LoA 1認定プログラム - 国立情報学研究所~
http://www.nii.ac.jp/userimg/6_gakunin_loa1_2013-11_v2.pdf

*参考 [#rb6016fa]

**OpenID [#n6f0aba7]
-OpenID Foundation website~
http://openid.net

***OpenID Financial API (FAPI) WG [#f4f721ee]
NRI、Microsoft、Intuitが中心となり組織されたWG。

-Financial API (FAPI) WG | OpenID~
http://openid.net/wg/fapi/

--Financial API | OpenID~
http://openid.net/tag/financial-api/

--openid / fapi — Bitbucket~
https://bitbucket.org/openid/fapi/

**nat [#a2685f07]
***OpenID Certification | OpenID [#fdcbdf3b]
http://openid.net/certification/

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

**インフル諸兄 [#jfe836ef]

***nat [#a2685f07]

-slideshare~
https://www.slideshare.net/nat_sakimura/presentations

--OpenID Foundation Foundation Financial API (FAPI) WG~
https://www.slideshare.net/nat_sakimura/openid-foundation-foundation-financial-api-fapi-wg-63097855

--Financial Grade OAuth & OpenID Connect~
https://www.slideshare.net/nat_sakimura/financial-grade-oauth-openid-connect

--API Days 2016 Day 1: OpenID Financial API WG~
https://www.slideshare.net/nat_sakimura/api-days-2016-day-1-openid-financial-api-wg

--OpenID Foundation FAPI WG: June 2017 Update~
https://www.slideshare.net/nat_sakimura/openid-foundation-fapi-wg-june-2017-update

--金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG~
https://www.slideshare.net/nat_sakimura/api-openid-financial-api-fapi-wg

--Introduction to the FAPI Read & Write OAuth Profile~
https://www.slideshare.net/nat_sakimura/introduction-to-the-fapi-read-write-oauth-profile

-金融APIに求められるセキュリティ~APIDays Paris講演より~
2017年2月号|金融ITフォーカス|刊行物|NRI Financial Solutions~
http://fis.nri.co.jp/ja-JP/publication/kinyu_itf/backnumber/2017/02/201702_8.html

**その他 [#q9bd8664]
-Financial API 実装の技術課題 - Qiita~
***TakahikoKawasaki [#yb98c811]
-Qiita

--Financial API 実装の技術課題~
https://qiita.com/TakahikoKawasaki/items/48a9d22205f77db59726

--【2019年版】世界最先端の API セキュリティー技術、~
実装者による『FAPI(Financial-grade API)』解説~
https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744

***tkudo [#kcd2bb84]
-FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication)~
https://www.slideshare.net/tkudo/fapi-ciba-2019-03-28

**勉強会 [#w494c7f7]
-OpenID BizDay で金融 API の動向について聞いてきた - TMD45'β'LOG!!!~
http://blog.tmd45.jp/entry/2017/08/02/011504

-FAPI Security について聞いてきた話(2017/08/18 社内勉強会)~
https://www.slideshare.net/tmd45/fapi-security-20170818

**OpenID Certification | OpenID [#fdcbdf3b]
http://openid.net/certification/
***OAuth & OIDC 勉強会(FAPI & CIBA 特集!) [#f941dfc8]

-仕様が正しく実装されているかどうか確認できる。
-『#OAuth & #OIDC 勉強会(#FAPI & #CIBA 特集)』ツイートまとめ - Togetter
--https://togetter.com/li/1309508
--https://authlete.connpass.com/event/111649/

-オンライン提供されているテスト・スイートを使う。
<FAPI>

-結果をSelf Certify して登録・公開~
→ FTC法5条の配下に入る。これによって信頼性を担保。
-Tokenエンドポイントでは~
Confidential Clientの認証を義務付けている(ただし、Basic 認証は不可)。

-ログも公開されるので、虚偽の申告は、他者が指摘可能。
--[[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)]] では、
---client_secret_jwt / private_key_jwt
---[[Mutual TLS (MTLS)>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]

-現在はOP Certification, RP Certificationが正式提供中。
--[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)]] では、~
※ [[OAUTB>OAuth 2.0 Token Binding]]の雲行きは怪しい。
---private_key_jwt
---[[Mutual TLS (MTLS)>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]

-FAPIにおいても、同様のスキームでテスト可能にする予定。
-トークン
--署名アルゴリズム
---[[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)]] では、特に指定なし(OIDCと同じ)。
---[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)]] では、PS256 と ES256 のみに限定する。

-ID トークン
--[[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)]] では、必須でない。
--[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)]] では、
---Hybrid Flowで認可応答に署名(Detatched Signature)する。
---[[JARM>JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)]]であればHybrid Flowでなくてもいい ≒ ID トークンは必須ではない。

-共通
--redirect_uriは、完全一致にしないといけない。

--Public Client

---SPA系は、~
[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)]] のHybrid Flowという選択肢もあるが、[[JARM>JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)]]でも可。

---ネイティブ系は、~
[[Claimed Https Scheme URI Redirection>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?Claimed%20Https%20Scheme%20URI%20Redirection]]を使用する。~
([[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)]]は[[PKCE>OAuth PKCE]]、[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)]]は+[[JARM>JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)]]?)~

--FAPI に準拠する API は、x-fapi-interaction-id HTTP ヘッダーを応答に含める。~
(クライアント側のログとサーバー側のログの付き合わせを容易にするために導入された仕組み)
---リクエストに x-fapi-interaction-id HTTP ヘッダーが含まれていればその値と同じ値
---そうでなければ UUID をサーバー側で生成

<[[CIBA>CIBA(Client Initiated Backchannel Authentication)]]>

**OSSコンソーシアム [#hbc189a4]
***開発基盤部会 Blog [#t5a7240c]
-Financial API Part 1 (Read Only API Security Profile) をサポートした話。~
https://www.osscons.jp/jo4uzqs3i-537/
-OAuth2/OIDC/FAPI2関連仕様、JAR、JARMを汎用認証サイトに実装しました。~
https://www.osscons.jp/jo21dkox6-537/

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


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS