Financial-grade APIについて

2018/7/31 (Tue)

メンバーシップチームの長島です。メンバーシップチームは主に日経ＩＤ認証・課金決済基盤の開発を行なっているチームで、私は課金・決済基盤の開発を担当しています。今後、課金決済システムにおいて銀行APIなどを利用する可能性を見据えてFinancial-grade APIについて調査しましたので、その簡単な概要とコンフォーマンステストについて書きたいと思います。

FAPI(Financial-grade API)について

FAPIはOpenID FoundationのWGが標準規格の策定を進めている金融データを3rd partyがセキュアに使用できるようにするためのAPI仕様のことを指します。

近年、FinTech関連のスタートアップが増えており、金融機関が持っているデータをセキュアに扱うことや銀行データをAPIを通じて広く扱えるようにするオープン化に関心が高まっています。

特に英国(UK)では国策としてOpen Bankingを謳っていて、Open Banking Implementation Entity（OBIE）という団体を設立し、そこで策定されたOpen Banking Profile（OBP）でFAPIが採用されています。

7/24, 25には「Japan/UK Open Banking and APIs Summit 2018」が開催され、その1日目には開発者向けのイベント「Financial APIs Workshop」が行われ、日本においてもFAPIについての情報発信が進んでいます。

FAPIがない場合

銀行がAPIを公開していなければ、FinTech企業がユーザの銀行アカウントへの認証情報をストアして、ユーザの代わりに銀行サイトのスクレイピングを行うというという方法で銀行データを取得する方法を用いざるを得ない状況になります。

FinTechサービスが国内外で増え、このような方法で銀行データが利用されていることに対して、銀行自らが安全なオープンAPIを公開することが求められるようになってきました。

それに対応する素直な流れとして、3rd partyに情報を提供するためにすでに多くのWebサービスで採用されているOAuth2.0 Frameworkを活用することが提案されました。

FAPI WGでは銀行APIのセキュリティ要件を満たすOAuth2.0プロファイルの策定を進めており、特にセキュリティに関するものは「Part 1: Read Only API Security Profile.」・「Part 2: Read & Write API Security Profile.」として定められています。

FAPI Part1, 2について

FAPIはPart1~5の仕様から構成されているのですが、現在Part1,2がImplementer’s Draftであり安定した仕様で、実装を始めても問題のない状態状態になっています。 Part1は口座情報の参照など参照のみのAPIを対象とし、Part2は送金など参照・更新を含むAPIを対象とした仕様です。具体的にFAPIで実現されていることをまとめると下記のようになるかと思います。

Read Only API Security Profile (Part 1)
- Code Flow(Bearer Token) + PKCE + MTLS
- Code Injectionへの対応 (PKCE)
- 長期Bearer Tokenの排除
Read & Write API Security Profile (Part 2)
- Hybrid Flow + JWS
- Sender Constraint Tokenが必須(MTLS or Token Binding)
- 認可リクエスト/レスポンスの保護 (JWS, s_hashの必須化)

セキュアにデータのやり取りをするためにIdentity Provider(IdP)・Clientとともに考慮しなければならないことは多くなりそうです。

コンフォーマンステスト

API提供側にしろ、利用する側にしろセキュアにデータをやり取りするためには、FAPIの仕様に則り正しい実装をすることが求められると思います。

なので、実装の正しさを証明するためにコンフォーマンステストを実施することはとても大切です。先日のFinancial APIs Workshopにおいて、fapi-conformance-suiteを開発したFinTechLabs.ioのジョセフ・ヒーナン氏もその重要性を主張していました。

元々はfapi-conformance-suiteはOpen Banking Profile（OBP） & FAPIのためのテストスイートとして開発されたのですが、現在ではHealthcare関連のデータをプライバシーを守りつつセキュアにアクセスするための仕様の策定を進めているHEARTのProfileにも対応しています。

このテストスイートはCIに組み込むことを想定して作られており、実装中からテストを行うことでより確実にコストを低くFAPIの実装を行うことを実現するものであると言えます。また、MavenでProject管理されており、Docker上で動かすことですぐにテストを始めることができる。実行環境にMavenとDockerが用意されていれば下記の手順でテストスイートを動作させることができます。

git clone https://gitlab.com/fintechlabs/fapi-conformance-suite.git
cd fapi-conformance-suite
mvn clean package
docker-compose up

Defaultではhttps://localhost:8443 にアクセスすることでテストスイートのWebインターフェースにアクセスすることができます。まず、テストプランを選び、JSONもしくはFormに入力する形式でIdPとClientなどの設定を行います。ここではIdPとしてOIDC Test Serverを使用しており、事前にIdPにClient情報を登録しておき、client_id, client_secret, scopeなどをclientの情報として設定する必要があります。

今回の設定内容

{
"server": {
    "discoveryUrl": "https://mitreid.org/.well-known/openid-configuration"
},
"client": {
    "client_id": [your client id],
    "client_secret": [your client secret],
    "scope": "openid email profile"
},
"tls": {
    "testHost": "mitreid.org",
    "testPort": "443"
},
"alias": "fintech"
}