金融機関サービス向けセキュリティ規格「FAPI」はどう使う？　その概要と活用法を解説

「FAPI」とは何か？

野田誠人氏：今日は、FAPIについて大まかに説明をいたします。

FAPIをご存じの方はいらっしゃいますか？　（挙手を見て）ありがとうございます。

FAPIの正式名称は、Financial-grade APIです。OpenID Foundationが策定しているOAuthとOpenID Connectのプロファイルの上に載せるプロファイルですね。

ファイナンシャルという名称がついているとおり、金融分野で使用されるOAuth、OpenID Connectのプロファイルを定義したものがFAPIです。

FAPIを採用している企業やプロダクトを紹介します。みんなの銀行、SBI（SBI DigiTrust）……Authleteから下は、プロダクトですね。「Authlete」や「Keycloak」などがあります。

みんなの銀行は企業ですが、Authleteを利用してFAPIに対応しています。そのため、今この分野では、Authleteが有名であることが数字的に言えるかなと思います。

「OAuth」は自分のデータを第三者が使用するための認可フローを定義したもの

「OAuthって何ぞや？」というところを少しおさらいしたいと思います。これは認可と呼ばれる分野で、自分のデータを第三者が利用していいですよという時に使用するフローを定義したものです。

1.0と2.0がありますが、今は基本的に2.0を使用するものと思って差し支えないと思います。Access Tokenとかがよく出てくるところで、あとは、Authorization: Bearerヘッダーとかでよく見かけるのが今では、だいたいこのOAuthです。

OAuthは、OpenID Foundationではなく、IETF（The Internet Engineering Task Force）のRFCで公開しています。

この簡単なフローは、全体がOAuthのフローではなく、上半分がOAuthのフローで、下半分は利用フローです。Introspectionと合わせると、3つのRFCを1つの流れで利用した図になっています。

ユーザーの認証情報を第三者が利用するための仕様「OpenID Connect」

次に、「OpenID Connectって何ぞや？」について。これはOAuthに被せて、ユーザーの認証情報をやり取りするための規格、仕様になっています。OpenID Foundationというところが定めています。

OAuthは、本当はIDの連携をしたり、「OAuthで認証されているからこのユーザーは正しい」とみなしたりしてはダメなのですが、それらを回避するID連携を実現するために、OAuthに載せた仕様になっています。

OAuthフローの説明

（スライドの）上のところがOAuthフローです。OAuthと一部違っているのはAccess Token だけではなくID Token も返ってきます。その下のID Token、User Infoは、Access Tokenを使ってデータを取得するところと同じですが、その途中にPublic Keyを取ってくることで、このOpenID Providerが発行したものだよということが検証できるようになっています。

このため、Access Tokenはどんな文字列でもよかったのですが、ID Tokenは基本的に、JWT（JSON Web Token）と決められています。

FAPIに存在する2つのプロファイル「Baseline」と「Advanced」の違い

もう少しFAPIを見ていこうと思います。BaselineとAdvancedという2つのプロファイルがあります。Baselineは、中程度のリスクを持つAPI向けで、Advancedは、より機密性の高い情報へアクセスするAPI向けです。

Baselineは、Read Onlyプロファイル、AdvancedはRead and Writeプロファイルと呼ばれているので、それをイメージすると使い方の切り替えがイメージしやすいかもしれません。

その一例として、Baselineは、Access Tokenの送信元が、Issuerが送ったユーザーであるということを検知するロールはなく、正当性のチェックはしていません。

Baselineの中から抜粋した部分なんですが、こんなふうにshallとかshouldとかでリストになっているんですね。FAPIは、箇条書きみたいになっているんです。

その中の一番下を見ると、クライアント認証では、client_secret_jwtとprivate_key_jwtの2つのどちらかを使うようにしましょうと定められています。

Advancedになると、もう少し厳しくなり、private_key_jwtだけにしなさいとなっています。そこまでに、client_secret_jwtっていうのは、クライアントに発行したシークレットを使った共通鍵での署名ですね。

private_key_jwtは、公開鍵と秘密鍵を使った非対称性の署名の検証で、より強いセキュリティのところでしか認めません。

FAPIはどう使っていくのがいいのか？

「どうやってFAPIを使っていこうか？」となると、何十項目もあるので、これに完全対応していくのは大変ですし、すでにある機能とバッティングする可能性もあります。

例えばFAPIには、x-fapi-interaction-idというヘッダーをつけて送信してきた場合には、それをそのまま返す。ヘッダーをつけて送信してこなかった場合には、ヘッダーにそれをつけてレスポンスを返す、というものがあります。

要は、内部の処理をトレーシングできるようにと、そういうのが定義されているのですが、そういうヘッダーはすでにあるといえばあったんですね。わざわざFAPIに対応するためにそれを書き替えるのはナンセンスじゃないですか。

なんでもかんでも全部対応していくのは、ナンセンスだしコストも高いのですが、チェックリストのように箇条書きになっているので、「これはやってみるとコストが低いけれども効果はあるな」と一つひとつ判断ができると思います。

一部を参考にするだけでも、自身が提供しているOAuthであれOpenID Connectであれ、セキュリティをより高めることができます。

すでにディスカッションが始まっているFAPI 2.0

次は、FAPI's Future。今まで紹介したのはFAPI 1.0の概要なんですが、実は2.0のディスカッションは2022年3月ぐらいから始まっています。

（スライドを示して）こちらはFAPI 2.0のBaselineで、Advancedと同等のセキュリティを実現するという目標のもと議論されています。

ただ、こんな感じで、認可レスポンスの検証なんかはissというフィールド、レスポンスのフィールドだけでやるという感じで、少し簡略化されていたりもします。

セキュリティを高めるために、これを使ってもいいですよというのがFAPIの1.0でも出ていたのですが、そのあたりをなるべくシンプルにしているのが2.0のBaselineです。

DPoPなどは、まだRFCでドラフト状態ですが、（スライドを示して）このように積極的に仕様に盛り込むような変更が加えられています。

FAPIは段階的な適用でも一部分だけの採用でも効果がある

最後に。FAPIは、セキュアなOAuthやOpenID Connectを提供するために進化し続けるチェックリストという扱いで使っていけるといいかなと思います。

段階的に適用してもいいし、一部分だけ採用してみても効果があると思います。ぜひ検討してみてください。

以上で、私の発表に代えさせていただきます。

（スライドを示して）こういうところにいろいろな資料が載っています。わからないところがあったら、ぜひ参考にしてください。

どうもありがとうございました。

（会場拍手）