デジタルバンク「みんなの銀行」ではBaaS APIを準備中ですが、高度なセキュリティを求められる銀行を始めとする金融事業者では、APIを公開するにあたり、それ以外の事業者に比べてより高いレベルでAPI、OAuth（FAPI）の実装が求められます。
BaaS（Banking as a Service）とAPI（Application Programming Interface）、APIのセキュリティ要件であるFAPI（Financial-grade API）について、ゼロバンク・デザインファクトリーで、サーバーサイドの開発を行うエンジニアの山﨑がお話します。
※この記事はオウンドメディア『みんなの銀行 公式note』からの転載です。
銀行機能をサービスとして提供する「BaaS」と、銀行と外部との間で安全なデータ連携を可能にする「API」
BaaSとは「銀行機能をサービスとして提供する」というもので、これにより、口座情報、決済、ローンなど様々な銀行機能の提供が可能になります。このBaaSの形態を実現させるための方法はいくつかありますが、その中の一つとしてAPIを介した方法があります。
APIとは、銀行と外部との間で安全なデータ連携を可能にする取組みです。このAPIを利用して銀行機能を外部に提供したり、他システムと連携させたりすることができます（API公開）。
APIのイメージが沸かないという人のために、次のパートでは、実際の店舗を持つ「A銀行窓口」と、スマホで全てのサービスが完結する「みんなの銀行アプリ」を例にして、その銀行機能の提供の流れを比較しながら確認していきたいと思います。
「銀行窓口」と「みんなの銀行アプリ」の銀行機能提供の流れを比較してみた
A銀行の窓口から
例えば、A銀行の窓口で出金や住所変更手続きなどを行う場合について考えます。「印鑑」「通帳」「本人確認書類」などが必要となることが多いですので、これらを窓口に持参し、内容に応じた「申込み用紙」に記入をして手続きを行います。
※本人確認書類の提示は、銀行によって取り扱いが異なる場合があります。
みんなの銀行のアプリから
次に、みんなの銀行アプリで出金や住所変更手続きなどを行う場合について考えます。みんなの銀行には実際の店舗（窓口）がないので、全ての手続きをアプリ上で行います。
A銀行の窓口での手続きには「印鑑」「通帳」「本人確認書類」などが必要となりますが、みんなの銀行アプリでの手続きには「ユーザーID」「パスワード（または生体認証）」「スマートフォン」（←通帳・キャッシュカードの代わりとなる、みんなの銀行口座と紐付いた特定のデバイス）が必要となります。これはスマートフォンと銀行口座が紐付けられているため、アプリがダウンロードされているスマートフォン自体が特定のデバイスであり、本人確認のための要素となっているからです。
またA銀行の窓口での手続きでは、「申込み用紙」に記入した情報は窓口が受け取りますが、みんなの銀行アプリでの手続きでは、「アプリを操作」して入力した情報はみんなの銀行のサーバーで受け付けます（APIリクエスト）。
サーバーは受け付けた情報を処理して、その結果をアプリに伝えます。この「情報を受け付け、結果を返す」という一連の処理を行うものが、APIです。ですのでAPIは、銀行窓口の役割を担うもの、と捉えても良さそうです（完全に一致するものではありませんが）。
BaaSでは第三者にAPIを公開
現在、みんなの銀行では「スマートフォン向けのアプリ」のみを提供していますので、みんなの銀行のAPIを使用できるのも、このアプリに限定されています。また、このアプリを使用するためには本人確認が必須なので、APIを使って口座にアクセスできるのは「本人のみ」ということになります。これは銀行窓口で手続きができるのは「本人のみ」という関係に似ていますよね。
この、本来「みんなの銀行アプリのみ＝本人のみ」に閉じられていたAPI を、みんなの銀行アプリ以外の第三者向けのAPIとして公開するのが、BaaSです。
でも第三者と聞くと……、銀行窓口の場合では家族や親しい関係者を思い浮かべるかもしれませんが、API の場合では、インターネット越しにリクエストを送信できる全てのアプリが対象になってきます。スマートフォンにダウンロードされている様々なアプリ、ECサイト、SNSなどのウェブサービスなどもその対象になります。これらのアプリがみんなの銀行のAPIを使えるようになることで、様々な銀行機能をアプリに組み込むことが可能になります。もっと詳しく知りたい方は、こちらのMinna no BaaSページ（https://baas.minna-no-ginko.com/#case）で公開しているUSE CASE（導入した場合の例）をご覧ください！
API を使う「権利」はどうやって確認するの？
「全てのアプリを対象にAPI を公開する！」とはいえ、誰でも自由にAPIを利用できるわけではありません。API 利用時には契約面、セキュリティ面から以下を確認する必要があります。
① API を使おうとしているのは誰なのか
② どの口座に対してのリクエストなのか
③ 第三者のアプリは該当の口座情報の取得、操作を行う権利があるか
しかしこの中で「③ 第三者のアプリは該当の口座情報の取得、操作を行う権利があるか」の確認は、非常に難しいのです。なぜかと言うと……もう一度、実際の銀行窓口での手続きを例にして考えてみます。
① Aさん（本人）以外の第三者が窓口にやってくる
② 第三者が「Aさんの口座から出金したい」と言う
③ 銀行窓口の担当者「〇〇〇〇〇〇〇〇〇〇……」
この場合、実際に第三者が他人の口座から出金できるかどうかはさておき、もしできるとすると、③の場面では、委任状のような書類が必要になるかもしれませんし、窓口の担当者がAさん（本人）に電話して、事実確認をするかもしれませんよね。
でも疑問も残ります。
「その委任状は本当にAさんが書いたものなのか？」
「窓口の担当者が電話で話した相手は、本当にAさんなのか？」
これらを確認することは、現実の世界においても非常に困難を極めるのです。
BaaS APIで使う「OAuth」って？
ではBaaSの場合はどうでしょう。API利用時に「③ 第三者のアプリは該当の口座情報の取得、操作を行う権利があるか」を確認するにはどうすれば良いのか、について正解を発表します！ OAuthという「認可」のフレームワークを使用します。これは「③ 第三者のアプリは該当の口座情報の取得、操作を行う権利があるか」の確認を実現するための、いくつかある方法のうちの一つになります。
「認可」というあまり聞き慣れない言葉や、「確認を実現するための方法」という回りくどい表現になっていますが、お察しの通り、少しややこしい話になっています。でもご安心ください。今回は、「認可」とそれと対で語られる「認証」について、少し触れるだけに留まりたいと思います（笑）。
「認証」と「認可」は組み合わせて使う
「認証」と「認可」は、ウェブアプリを開発されている方であれば耳なじみがあるかもしれませんが、英語では、Authentication（認証）とAuthorization（認可）。似ている言葉なのでどっちがどっちか分からなくなりますが（笑）、それぞれが意味するのは、「認証」は誰であるか？ 「認可」は権限があるか？ ということです。
■ 認証 ― 誰であるか ―
先ほど銀行機能の提供の流れでお話しましたが、アプリでは、 「ユーザーID」「パスワード（または生体認証）」を組み合わせて、認証 – 本人であるか – を示すことが多いのですが、「認証」とは「ユーザーID」と「パスワード」を示した相手が誰であるかを確認することです。
■ 認可 ― 権限があるか ―
では「認可」とは何でしょうか。例えば家の鍵を例に挙げます。家の鍵を持っていれば、玄関のドアを開けて家の中に入ることができます。これは家に入る「権限」があることを示しており、家の鍵は「権限」を証明するためのものになります。そう、鍵を持ってさえいれば、その鍵の持ち主が誰であるかはあまり関係がなくなるのですが、そうなると誰でも鍵を使って家に入れてしまって困るので、「認可」と「認証」は組み合わせて使われることが多いのです。
先ほど、BaaSのAPI利用時に「③ 第三者のアプリは該当の口座情報の取得、操作を行う権利があるか」を確認するには、「認可」のフレームワークOAuthを使うとお話しましたが、つまり、OAuthは、アプリ上で家の鍵を第三者に渡す方法と「検証」すべき内容を示すフレームワークなのです。
続く―― FAPI（Financial-grade API）
今回は APIを公開するということを銀行窓口と比較しながら紹介し、「認証」と「認可」についても簡単に触れました。実際の実現方法や、セキュリティをどのように担保するのかに興味が湧いた方もいらっしゃると思うので、次回は、海外と国内におけるAPI公開の動きとその背景、OAuthとその拡張仕様であるFAPI（Financial-grade API）についてお話できればと思います。
