はじめに

『FAPI-CIBA プロファイル』という新仕様が 2019 年 8 月に承認されました（アナウンス）。

Financial-grade API: Client Initiated Backchannel Authentication Profile

この仕様は、FAPI（Financial-grade API）と CIBA（Client Initiated Backchannel Authentication）を同時に運用する際に従うべき追加の要求事項を定義しています。

この記事では、FAPI-CIBA プロファイルを紹介します。FAPI と CIBA 自体については、それぞれ次の記事を参照してください。

認可サーバーに対する要求事項

認可サーバーに対する要求事項は「5.2.2 Authorization Server」に列挙されています。FAPI に従った上で、さらに下記が要求されます。

1	shall only support Confidential Clients for Client Initiated Backchannel Authentication flows;
	CIBA フローを使えるのはコンフィデンシャル・クライアントのみ

CIBA Core 仕様がコンフィデンシャル・クライアントしか許していないので、この要求事項は新しい制限事項ではなく、既存の制限事項を確認しているに過ぎません。

2	shall ensure unique authorization context exists in the authorization request or require a `binding_message` in the authentication request;
	認可コンテキストが一意であることを保証するか、または、バックチャネル認証リクエストの `binding_message` パラメーターを必須とすること

「認可コンテキストが一意であることを保証する」というのは抽象的な表現で、その実現方法は各実装に任されます。単純な実装にしたければ、バックチャネル認証リクエストの binding_message を必須パラメーターとして要求すればよいです^※。

^{※ Authlete には「バックチャネル認証リクエストが FAPI リクエストと判定された際に binding_message を必須とする」という設定項目が用意されています。}

3	shall not support CIBA push mode;
	PUSH モードをサポートしてはならない

CIBA には、POLL、PING、PUSH モードという三つのモードがありますが、これらのうち、PUSH モードのサポートが禁止されます。

POLL モードと PING モードでは、トークン群はトークンエンドポイントから発行されます。一方、PUSH モードでは、クライアントに対する通知の中に直接トークン群を埋め込みます。この PUSH モードの動作は新しく、業界で使い込まれたものではないため、FAPI-CIBA プロファイルでは安全側に倒して PUSH モードを禁止することになりました。

4	shall support CIBA poll mode;
	POLL モードをサポートしなければならない

5	may support CIBA ping mode;
	PING モードをサポートしてもよい

6	shall require Backchannel Authentication Endpoint requests to be signed as described in [CIBA] 7.1.1;
	バックチャネル認証リクエストは署名されていなければならない

CIBA のフローは全て、バックチャネル認証エンドポイントというエンドポイントにリクエストを送るところから始まります。RFC 6749 で定義される認可エンドポイントは CIBA フローでは使われません。

通常のリクエストは、scope、acr_values、login_hint などのリクエストパラメーター群を application/x-www-form-urlencoded 形式で一つずつ指定します。一方、これらのパラメーター群を一つの JWT にまとめ、その JWT を request パラメーターの値として指定する方法もあります。この方法は CIBA Core の「7.1.1 Signed Authentication Request」で定義されています。

FAPI-CIBA プロフィアルでは、全てのバックチャネル認証リクエストは「request={JWT}」形式でなければなりません。

7	shall require user authentication to an appropriate level for the operations the client will be authorized to perform on behalf of the user;
	クライアントが要求する権限に応じ、適切なレベルのユーザー認証をしなければならない

8	shall, if it supports the `acr` claim and the client has requested `acr`, return an '`acr`' claim in the resulting ID token;
	認可サーバーが `acr` クレームをサポートしているなら、クライアントが（`acr_values` リクエストパラメーターなどで）`acr` を要求したなら、ID トークンに `acr` クレームを埋め込まなければならない

9	shall require the Signed Authentication Request to contain `nbf` and `exp` claims that limit the lifetime of the request to no more than 60 minutes;
	JWT 形式のバックチャネル認証リクエストは `nbf` クレームと `exp` クレームを含まなければならず、JWT の生存期間は 60 分以内でなければならない

10	may require clients to provide a `request_context` claim as defined in section 5.3 of this profile; and
	バックチャネル認証リクエストに `request_context` パラメーターが含まれることを要求してもよい

request_context パラメーターは FAPI-CIBA プロファイルの「5.3. Extensions to CIBA authentication request」で新たに追加されるリクエストパラメーターです。CIBA Core には存在しません。

11	should not use the `login_hint` or `login_hint_token` to convey "intent ids" or any other authorization metadata
	認可リクエストに付随するメタデータを格納する場所として `login_hint` や `login_hint_token` を流用してはならない

login_hint や login_hint_token（および id_token_hint）は、認証対象となるユーザーを特定するために使われるリクエストパラメーターです。これらを他の用途に流用しないように、という注意書きです。

login_hint と login_hint_token の値のフォーマットが決まってないことをいいことに、英国オープンバンキングの「インテント ID」を無理矢理これらのパラメーターに詰め込もうと画策する勢力があったのですが、それは悪いアイディアなので、FAPI-CIBA プロファイルで明示的に禁止することにしました。

クライアントに対する要求事項

クライアントに対する要求事項は「5.2.3.1. General Provisions」と「6.2. Client Provisions」に規定されています。

5.2.3.1 の項目は認可サーバーに対する要求事項の裏返しで、次が要求されます。

request={JWT}
一意な認可コンテキストもしくは binding_message
適切なユーザー認証

6.2 の規定は次の通りです。

1	shall not send `x-fapi-customer-ip-address` or `x-fapi-auth-date` headers; and
	`x-fapi-consumer-ip-address` ヘッダーや `x-fapi-auth-date` ヘッダーを送信してはならない

x-fapi-consumer-ip-address や x-fapi-auth-date は、FAPI Part 1 の「6.2.2 Client provisions」に登場するヘッダーです。

2	should send metadata about the consumption device, for example geolocation and device type.
	位置情報やデバイスタイプなど、コンサンプション・デバイスに関する情報を送るべきである

コンサンプション・デバイス（consumption device）とは、CIBA Core に出てくる概念で、クライアントアプリケーションが動作するデバイスをさします。

セキュリティ上の考慮事項

「7. Security Considerations」では、セキュリティ上の考慮事項が挙げられています。

バックチャネル認証リクエストの user_code パラメーターや binding_message パラメーターを活用するべき、PUSH モードは禁止、などということが書かれています。

TLS の暗号スイートに関する制限は FAPI Part 2 と同様です。ただし、FAPI も FAPI-CIBA プロファイルも、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 と TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 を暗号スイートの許可リストに含めるべきです。これについては次の Issue で提案しており、TLS の専門家の Ivan Ristic さん（『Bulletproof SSL and TLS』の著者）からもコメントをもらえていますが、まだ仕様書に反映されていません。

Issue #216: TLS_ECDHE_ECDSA cipher suites

JWS の署名アルゴリズムに関する制限も FAPI Part 2 と同様で、ES256 と PS256 しか許されません。

FAPI Implementer's Draft 2 では言及されていませんが、FAPI-CIBA プロファイルでは暗号アルゴリズムにも言及しており、RSA1_5 は禁止されています。

FAPI-CIBA プロファイル認証プログラム

FAPI-CIBA プロファイル用の公式認証プログラムが 2019 年 9 月に開始されました（アナウンス）。認証を受けた実装は Certification ページの #FAPI-CIBA_OPs に列挙されています。

本記事執筆時点（2019 年 10 月 8 日）で、FAPI-CIBA プロファイルの認証を受けているのは、世界で Authlete（オースリート）のみです。Authlete 社が最初に認証を取得したことについては、OpenID Foundation のアナウンスでも次のように言及されています。Authlete すごい！^*

Despite the FAPI-CIBA specification being relatively new, it has already been adopted by OpenBanking UK as well as OpenID Foundation members Authlete, Ping Identity, and Ozone Financial Technology. Authlete was the first to achieve FAPI-CIBA certification and we look forward to many more FAPI-CIBA certifications in the near future.

^{* DISCLAIMER: 本記事執筆者は Authlete, Inc. の共同創業者です}

おわりに

「FAPI かつ CIBA」というかなり尖った組み合わせであるため、自分が記事を書かないと日本語情報がなかなか出てこないであろうことに気付き、急遽記事を書くことにしました。世界最先端を走る OAuth & OIDC の実装である Authlete をよろしくお願いします！

API World 2019 を直前に控えた San Jose の宿にて