第2回では、海外と日本におけるAPI公開の動きや、API仕様の開発標準策定の成り立ち、開発標準の一つである認可のOAuth、FAPI（Financial-grade API）の概念についてお話しました。
最終回では、OAuthの実際のフローや攻撃されやすいポイント、その拡張仕様FAPIについて、ゼロバンク・デザインファクトリーで、みんなの銀行のサーバーサイドの開発を行うエンジニアの山﨑がお話します。
※この記事はオウンドメディア『みんなの銀行 公式note』からの転載です。
認可「OAuth」――家の鍵を第三者に渡す方法を、現実の世界で考えてみる
OAuthは、アプリケーション上で家の鍵を第三者に渡す方法と「検証」すべき内容を示すフレームワーク、と前回お話ししました。
現実の世界においては、家の鍵を第三者に渡す方法の一つとして「手渡し」が考えられると思います。しかし下の例のように、手渡しができない場合はどうしたら良いのでしょうか？
Q. 突然の福岡への長期出張。Aさんは、1ヵ月の間、東京の自宅（賃貸物件）を空けることになりました。Aさんは、出張で不在にしている間に、東京の自宅を綺麗にしたいと考え、家事代行業者に掃除を依頼することにしました。すでに福岡に出張中のAさんが、家の鍵を第三者である家事代行業者に渡すには、どのような方法が考えられるでしょうか？
家の鍵を家事代行業者に郵送で渡すことも考えられますが、郵便物の紛失や盗難の心配も残ります。そこでAさんは、自宅（賃貸物件）の持ち主である大家さんに連絡して、大家さんが管理しているAさんの家の鍵（合鍵）を、第三者である家事代行業者に渡してもらおうと考えました。
しかし大家さんが多忙で、Aさんの家の鍵を家事代行業者に「手渡し」してもらうことができないため、鍵の受け渡しはロッカーで行うことに決まりました。Aさんが考えた、掃除の当日のフローがこちらです（下の図）。
・「Aさん」は
・「電話」で
・「家事代行業者」に連絡をして、掃除をお願いする。また、
・家事代行業者が、Aさんの「家」に入るために
・「大家」さんから
・鍵の入っているロッカーの「暗証番号」を教えてもらい
・家の「鍵」を受け取るようにお願いする。
こうしてAさんは、出張先の福岡にいながらにして、家の鍵を家事代行業者（第三者）に渡すことに成功しました！ 大家さんが家の鍵を入れたロッカーの暗証番号を家事代行業者（第三者）に教える前に、Aさんに確認も入れていますね。
「大家さんが家事代行業者にAさんの家の鍵を渡すフロー」は、OAuthの「認可コードフロー」に似ている！
実はAさんが考えた、この「大家さんが家事代行業者にAさんの家の鍵を渡すフロー」は、OAuthの「認可コードフロー」というものに、とてもよく似ているのです。上の図は、左が「大家さんに鍵を渡すフロー」に出てくるワードで、右がこれに対応する「認可コードフロー」に出てくるワードを一覧にしたものです。
まず前提として、ユーザー（Aさん）は、資産管理サービス（家事代行業者）で取引履歴を表示したいと考えていますが、取引履歴を表示するためには、銀行API（家）のアクセストークン（家の鍵）が必要となります。それでは「認可コードフロー」上で、認可サーバー（大家）から資産管理サービス（家事代行業者）にアクセストークン（家の鍵）を取得させる「APIアクセスのフロー」を見ていきましょう。
1.連携開始
取引履歴を連携したいので、資産管理サービス（家事代行業者）にアクセスして、銀行API（家）との連携開始のメニューを選択します。すると画面には銀行API（家）のアカウントにログインするための画面が表示されます。
・Aさんが家事代行業者に掃除を依頼すると、大家さんから確認の電話がかかってくる
2.認証と認可
ユーザー（Aさん）が、銀行API（家）のアカウントにログイン＝認証し、資産管理サービス（家事代行業者）が取引履歴取得APIを使用することを許可＝認可します。
・Aさんは大家さんからの電話に出て、家事代行業者に家の鍵を渡すこと＝家に入ることを許可する
3.鍵の取得
ユーザー（Aさん）から銀行API（家）の使用の許可が下りたので、アクセストークン（家の鍵）を取得するための認可コード（ロッカーの暗証番号）を資産管理サービス（家事代行業者）に渡します。資産管理サービス（家事代行業者）は、認可コード（ロッカーの暗証番号）とアクセストークン（家の鍵）を引き換えます。
・Aさんから鍵を渡す許可が下りたので、大家さんはロッカーの暗証番号を家事代行業者に伝える
・家事代行業者はロッカーを開け、Aさんの家の鍵を受け取る
4.APIを使用する
資産管理サービス（家事代行業者）は、取引履歴取得APIの使用時にアクセストークン（家の鍵）をAPIリクエストに含めます。銀行API（家）は、アクセストークン（家の鍵）が正当なものかを確認し、正当なものであれば取引履歴を返します。
・家事代行業者は、家に入るために受け取った鍵を使用する
・この鍵がAさんの家のものであれば鍵を開けることができ、家事代行業者は家の中に入ることができる
ここでの注目ポイントは、ユーザー（Aさん）は、資産管理サービス（家事代行業者）の「取引履歴の連携開始」と「ログイン＋認可」を行うだけで、銀行API（家）と資産管理サービス（家事代行業者）の連携がセキュアに行われ、サービスを利用できるようになるということです。
OAuth の脆弱性 金融事業者のサービスでは不十分？
ここまでOAuthの「認可コードフロー」のポイントを説明してきましたが、ところが、OAuth にはいくつか攻撃されやすいポイントもあります。これらの攻撃されやすいポイントは、 Internet Engineering Task Force（IETF）によるドキュメント、脅威モデルRFC6819でまとめられており、その対応策についても記載されています。
https://datatracker.ietf.org/doc/html/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対応のものをお届けする予定ですので、どうぞご期待ください！
