ここのところFintechに関わっている西川です。（今日はDockerおじさんではありません）
Fintechという分野は去年改正された銀行法で謳われている「オープンAPIの体制整備に努めること」を首を長くして待っていた業界かと思います。今日はこちらについて、人のふんどしでサックリと紹介していきたいと思います。なんと言っても2/14はふんどしの日ですからね。
なぜオープンAPIを待ち望んでいたのか
早速cnetさんの記事を引用します。
結果的に当社を含む多くの自動家計簿ツールが、ユーザーのデータを参照するために契約者番号やパスワードをセキュアな環境で預かり、代理でデータ取得する方法を採用してきた。ただし、パスワードを預かる構図は、家計簿や会計ソフトサービス側も望むところではなかった
この記事は家計簿アプリの最大手マネーフォワードの瀧氏によって書かれています。ここで述べられていることを一言で言うと「WEBスクレイピングからの卒業」です。
なぜ卒業したいのでしょうか？ 答えは「セキュリティ」です。
上記の記事でも述べられていますが、スクレイピング方式ではユーザーからパスワードを預かる必要があります。スクレイピングする過程でログイン認証をクリアしないと必要な情報に辿りつけないため仕方なしというスタンスです。インターネットバンキングのパスワードなどは重要情報なので、事業者としてもできれば預かりたくは無いというのが本当のところです。
オープンAPI化されることで導入されるOAuth2.0がこれを解消してくれるのです。
OAuth2.0
次のふんどしはAuthlete川崎氏のQiitaです。
重要なのは「第三者のアプリケーションにユーザーの ID & パスワードを渡さない」という点です。これを実現したいがために OAuth があります。
詳細は省くのですが、パスワードを渡さない代わりにOAuth2ではアクセストークンというものを発行して渡します。
アクセストークンは一日乗車券のようなもので、
- 一定期間のみ利用可
- 限定された操作だけが許可される
というものです。
パスワードを渡してしまった場合、自分のアカウント操作権を無期限に与えてしまうという他に、パスワードの変更権限までも渡していることになります。悪意のある者にパスワードを渡してしまったらパスワード変更されて完全に乗っ取られてしまうことになります。
このようなことを防ぐために必要最小限の操作権と使用期限が設けられたアクセストークンを使います。このアクセストークンとその発行にまつわる仕様がOAuth2です。
OAuth2はどこから出てきたのか
OAuth2自体は随分前からある仕様ですが、「銀行APIにOAuth2を採用する」というのがどこから出てきたのかという話です。
全銀協のオープン API のあり方に関する検討会報告書というレポートがあります。
その中にこんな一文があります。
「認可プロトコル」として、OAuth2.0 認可フレームワーク（以下「OAuth2.0」という。）を推奨する。
全銀協としてもOAuth2を推奨しているのですが、この考えのルーツはFintech先進国であるイギリスのOpenBankingStandardというレポートにあります。
このレポートのセキュリティに関する記述としてOAuth2.0が推奨されているため、日本でもこれに倣った形です。イギリスのふんどしですね。
そしてFAPI
FAPIはFinancial API の略称です。
Fintech先進国であるイギリスでは先んじて銀行APIが開発されてきましたが、その過程で標準化が提唱されました。
標準化の内容としては、
- 各種APIエンドポイントのインターフェース仕様
- セキュリティ仕様
といったもので、セキュリティ仕様に関してはSecurity Profile（以下FAPI SP）として定義されています。
ところで先に紹介した全銀協の検討報告書には以下の記述もあります。
なお、金融分野における API への OAuth2.0 の適用に関する詳細仕様は、2017 年６月現在、OpenID Foundation Financial API WG（FAPIWG）において、セキュリティ水準を確保する観点から、標準化作業が実施されている。同団体で OAuth2.0 適用の詳細仕様が発行された際には、各銀行において同仕様への準拠や準拠に向けた方針等が検討されることが望ましい
少し微妙な書き方ですが、これはFAPI SPを示唆したものと思われます。
私がここでなぜFAPI SPを持ちだしたのかを明かすと、色々調べていくうちにFAPI WGのコアメンバーであるJoseph氏から「英国の銀行はOAuth2だけでは不足するセキュリティを各々独自仕様で実装してきて、その結果として標準を策定する運びになった」ということを聞いたためです。日本でも同様の道筋をたどることになるのは想像に難くなく、それであれば最初からFAPI SPを視野に入れておいたほうが良いでしょうということで紹介させていただきました。
FAPI SPの概要はまたもやAuthlete川崎氏のQiitaを他人のふんどしとして借ります。
この記事の中では、例えばこんなことが述べられています。
トークン所有者とトークンの紐付け
これはOAuth2で述べられているアクセストークンの欠点を補うものです。
単純なアクセストークンは１日乗車券のメタファー通り、別の人がそれを奪って電車に乗りまくる事が出来得ます。それを防ぐためには航空券のように本人確認を伴う仕組みが必要で、上記の件（トークンバインディング、mutual TLSの使用）はそれを意図してFAPI SPに定義されたものです。
という具合にFAPI SPにはイギリスの銀行API開発者たちが経験した「ああっ、これやらなきゃ・・・」という貴重なノウハウが詰め込まれているのです。
後進の日本としてはどこまで採用するかは議論の余地がありますが、内容は把握しておくべきでしょう。
まとめ
いかがでしたでしょうか。 Fintechと大きく関係する銀行APIとそのセキュリティについてざっと書かせていただきました。
OAuth2を始めとするOpenID Foundationの仕様はとても重要なのですが、かなり難解で私もこれらの知識を習得するにはかなり苦労しました。この分野に興味を持った方の入り口としてお役に立てたなら幸いです。
それでは、２（ふぅん）１４（どぉしぃ）！
