こんにちは、ゼロバンク・デザインファクトリー（※）の山﨑です。前編ではBaaS（Banking as a Service）で第三者にAPI（Application Programming Interface）を公開するということ、「認証」と「認可」の組み合わせについてお話し、中編では海外と日本におけるAPI公開の動きや、API仕様の開発標準策定の成り立ち、開発標準の一つである認可のOAuth、FAPI（Financial-grade API）の概念についてお話しました。最終回となる後編では、OAuthの実際のフローや攻撃されやすいポイント、その拡張仕様FAPIについて具体的にご紹介していきます。
※ゼロバンク・デザインファクトリーは、ふくおかフィナンシャルグループの一員で、みんなの銀行のバンキングシステムを開発しています。

👇前編はこちら！

👇中編はこちら！

認可「OAuth」――家の鍵を第三者に渡す方法を、現実の世界で考えてみる

OAuthは、 アプリケーション上で家の鍵を第三者に渡す方法と「検証」すべき内容を示すフレームワーク、と前編でお話ししました。

現実の世界においては、家の鍵を第三者に渡す方法の一つとして「手渡し」が考えられると思います。しかし下の例のように、手渡しができない場合はどうしたら良いのでしょうか？

家の鍵を家事代行業者に郵送で渡すことも考えられますが、郵便物の紛失や盗難の心配も残ります。そこでAさんは、自宅（賃貸物件）の持ち主である大家さんに連絡して、大家さんが管理しているAさんの家の鍵（合鍵）を、第三者である家事代行業者に渡してもらおうと考えました。

しかし大家さんが多忙で、Aさんの家の鍵を家事代行業者に「手渡し」してもらうことができないため、鍵の受け渡しはロッカーで行うことに決まりました。Aさんが考えた、掃除の当日のフローがこちらです（下の図）。

こうしてAさんは、出張先の福岡にいながらにして、家の鍵を家事代行業者（第三者）に渡すことに成功しました！　大家さんが家の鍵を入れたロッカーの暗証番号を家事代行業者（第三者）に教える前に、Aさんに確認も入れていますね。

「大家さんが家事代行業者にAさんの家の鍵を渡すフロー」は、OAuthの「認可コードフロー」に似ている！

実はAさんが考えた、この「大家さんが家事代行業者にAさんの家の鍵を渡すフロー」は、OAuthの「認可コードフロー」というものに、とてもよく似ているのです。上の図は、左が「大家さんに鍵を渡すフロー」に出てくるワードで、右がこれに対応する「認可コードフロー」に出てくるワードを一覧にしたものです。

まず前提として、ユーザー（Aさん）は、資産管理サービス（家事代行業者）で取引履歴を表示したいと考えていますが、取引履歴を表示するためには、銀行API（家）のアクセストークン（家の鍵）が必要となります。それでは「認可コードフロー」上で、認可サーバー（大家）から資産管理サービス（家事代行業者）にアクセストークン（家の鍵）を取得させる「APIアクセスのフロー」を見ていきましょう。

１．連携開始
取引履歴を連携したいので、資産管理サービス（家事代行業者）にアクセスして、銀行API（家）との連携開始のメニューを選択します。すると画面には銀行API（家）のアカウントにログインするための画面が表示されます。

２．認証と認可
ユーザー（Aさん）が、銀行API（家）のアカウントにログイン＝認証し、資産管理サービス（家事代行業者）が取引履歴取得APIを使用することを許可＝認可します。

３．鍵の取得
ユーザー（Aさん）から銀行API（家）の使用の許可が下りたので、アクセストークン（家の鍵）を取得するための認可コード（ロッカーの暗証番号）を資産管理サービス（家事代行業者）に渡します。資産管理サービス（家事代行業者）は、認可コード（ロッカーの暗証番号）とアクセストークン（家の鍵）を引き換えます。

４．APIを使用する
資産管理サービス（家事代行業者）は、取引履歴取得APIの使用時にアクセストークン（家の鍵）をAPIリクエストに含めます。銀行API（家）は、アクセストークン（家の鍵）が正当なものかを確認し、正当なものであれば取引履歴を返します。

ここでの注目ポイントは、ユーザー（Aさん）は、資産管理サービス（家事代行業者）の「取引履歴の連携開始」と「ログイン＋認可」を行うだけで、銀行API（家）と資産管理サービス（家事代行業者）の連携がセキュアに行われ、サービスを利用できるようになるということです。

OAuth の脆弱性　金融事業者のサービスでは不十分？

ここまでOAuthの「認可コードフロー」のポイントを説明してきましたが、ところが、OAuth にはいくつか攻撃されやすいポイントもあります。これらの攻撃されやすいポイントは、 Internet Engineering Task Force（IETF）によるドキュメント、脅威モデルRFC6819でまとめられており、その対応策についても記載されています。

しかし、高度なセキュリティを求められる銀行を始めとする金融事業者のサービスの場合では、脅威モデルRFC6819に書かれた対応策で十分なのでしょうか？　十分なセキュリティ対策ができていることを、より強く示すにはどのような方法があるのでしょうか？

より安全に実装するための、OAuthの拡張仕様「FAPI」

ここで、OAuthをより安全に実装するための拡張仕様FAPI（Financial-grad API）が登場します。

FAPIの仕様は、金融グレードAPI（FAPI）セキュリティ・プロファイル「Financial-grade API Security Profile 1.0」のPart１の参照系API（Baseline）と、Part 2の更新系（Advanced）に分かれており、Part 2の更新系は、よりセキュリティに対する要求が高くなっています。

FAPIについてすべての仕様をご紹介するのは難しいので、今回はPart 2の更新系における「mTLSによる証明書のアクセストークン」についてお話します。詳しく知りたい方は以下をご覧ください。

証明書を要求し、クライアントが「誰なのか？」を確認する「mTLS」

ブラウザ上でウェブサイトを開くと、アドレスバーの左横に鍵マークが表示されますが、その鍵マークをクリックして進むと証明書が表示されます（上の図）。この証明書は、ウェブサイトを運営しているのが「誰なのか？」ということを証明するためのものです。

✅ 通常のTLSとmTLS

そして、上の図で示しているように、ウェブサイトのHTTPS通信の場合、ウェブサイト側（サーバー側）のみが証明書を表示します。これは、通常のTLS（Transport Layer Security）と呼ばれるもので、安全性の高い通信を行うプロトコルです。

一方で、ウェブサイト側（サーバー側）が証明書を表示するだけでなく、このウェブサイトにアクセスするクライアント（ユーザーが操作する端末やアプリ、ブラウザ等）側にも証明書を要求し、クライアントが「誰なのか？」を確認するのが、mTLS（Mutual Transport Layer Security）です。

✅ アクセストークンと証明書（mTLS）

しかしOAuthをより安全に実装するための拡張仕様、FAPIのPart 2の更新系では、アクセストークンは発行された本人しか使用できないようにすることを要求しています。認可サーバーは、mTLSによって得たクライアントの証明書とアクセストークンを紐付けて管理することで、これを実現します（上の図）。もし攻撃者がなんらかの方法でアクセストークンを盗んだとしても、「アクセストークンに紐づく証明書とセット」でなければ使用することができず、よりセキュアな状態で APIを公開することが可能になるという訳です。

終わりに

このように、高度なセキュリティを求められる銀行を始めとする金融事業者では、APIを公開するにあたり、それ以外の事業者に比べてより高いレベルでAPI、OAuth（FAPI）を実装する必要があるのです。現在みんなの銀行ではBaaS APIを準備中ですが、金融グレードのセキュリティを担保したFAPI対応のものをお届けする予定ですので、どうぞご期待ください！

さて、前・中・後編にわたって、BaaS APIやその仕様、認可OAuthのフロー、その拡張仕様FAPIなどについてお話してきました。システムマガジンの次のnoteでは、みんなの銀行が認証認可機能の実装に利用しているSaaS「Authlete」について、担当者の方にインタビューを実施していきたいと思います！