FAPI-CIBA プロファイル

# はじめに

『**FAPI-CIBA プロファイル**』という新仕様が 2019 年 8 月に承認されました（[アナウンス](https://openid.net/2019/08/23/implementers-draft-of-fapi-client-initiated-backchannel-authentication-ciba-profile-approved/)）。

* [Financial-grade API: Client Initiated Backchannel Authentication Profile](https://openid.net/specs/openid-financial-api-ciba-wd-02.html)

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

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

* [世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説](https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744)
* [世界最先端の認証認可技術、実装者による『CIBA』解説](https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3)

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

認可サーバーに対する要求事項は「[5.2.2 Authorization Server](https://openid.net/specs/openid-financial-api-ciba-wd-02.html#authorization-server)」に列挙されています。FAPI に従った上で、さらに下記が要求されます。

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

[CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) 仕様がコンフィデンシャル・クライアントしか許していないので、この要求事項は新しい制限事項ではなく、既存の制限事項を確認しているに過ぎません。

|2|shall ensure unique authorization context exists in the authorization request or require a `binding_message` in the authentication request;|
|:-:|:--|
||認可コンテキストが一意であることを保証するか、または、[バックチャネル認証リクエスト](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1)の `binding_message` パラメーターを必須とすること|

「認可コンテキストが一意であることを保証する」というのは抽象的な表現で、その実現方法は各実装に任されます。単純な実装にしたければ、[バックチャネル認証リクエスト](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1)の `binding_message` を必須パラメーターとして要求すればよいです<sup>※</sup>。

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

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

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

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

<img width="696" alt="ciba-push-mode.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106044/8f8fdc1d-6b9c-4777-656c-82c446b5f5dc.png">

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

<img width="695" alt="ciba-poll-mode.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106044/a6428915-ab07-7725-30ac-d95998f5c8a8.png">

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

<img width="696" alt="ciba-ping-mode.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106044/c25fa02a-1927-f361-d8b2-eee0b8d85d1a.png">

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

CIBA のフローは全て、**バックチャネル認証エンドポイント**というエンドポイントにリクエストを送るところから始まります。[RFC 6749](https://tools.ietf.org/html/rfc6749) で定義される認可エンドポイントは CIBA フローでは使われません。

![backchannel_authentication_request.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106044/798c9a30-814c-5c05-3518-e49ba312f82a.jpeg)

通常のリクエストは、`scope`、`acr_values`、`login_hint` などのリクエストパラメーター群を application/x-www-form-urlencoded 形式で一つずつ指定します。一方、これらのパラメーター群を一つの JWT にまとめ、その JWT を `request` パラメーターの値として指定する方法もあります。この方法は CIBA Core の「[7.1.1 Signed Authentication Request](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1.1)」で定義されています。

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

|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](https://openid.net/specs/openid-financial-api-ciba-wd-02.html#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](https://openid.net/specs/openid-financial-api-ciba-wd-02.html#general-provisions)」と「[6.2. Client Provisions](https://openid.net/specs/openid-financial-api-ciba-wd-02.html#client-provisions)」に規定されています。

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

1. <code>request=<i>{JWT}</i></code>
2. 一意な認可コンテキストもしくは `binding_message`
3. 適切なユーザー認証

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](https://openid.net/specs/openid-financial-api-part-1-ID2.html#client-provisions)」に登場するヘッダーです。

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

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


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

「[7. Security Considerations](https://openid.net/specs/openid-financial-api-ciba-wd-02.html#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](https://www.linkedin.com/in/ivanr/) さん（『[Bulletproof SSL and TLS](https://www.feistyduck.com/books/bulletproof-ssl-and-tls/)』の著者）からもコメントをもらえていますが、まだ仕様書に反映されていません。

* [Issue #216: TLS_ECDHE_ECDSA cipher suites](https://bitbucket.org/openid/fapi/issues/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 月に開始されました（[アナウンス](https://openid.net/2019/09/16/openid-certification-program-expands-with-the-release-of-financial-grade-api-client-initiated-backchannel-authentication-profile-fapi-ciba-certification/)）。認証を受けた実装は [Certification ページ](https://openid.net/certification/)の [#FAPI-CIBA_OPs](https://openid.net/certification/#FAPI-CIBA_OPs) に列挙されています。

![FAPI-CIBA_OPs_20190920.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/106044/8864683e-10d5-3848-ce15-7a215904ffa5.png)

本記事執筆時点（2019 年 10 月 8 日）で、FAPI-CIBA プロファイルの認証を受けているのは、**世界で [Authlete](https://www.authlete.com/)（オースリート） のみです**。Authlete 社が最初に認証を取得したことについては、OpenID Foundation の[アナウンス](https://openid.net/2019/09/16/openid-certification-program-expands-with-the-release-of-financial-grade-api-client-initiated-backchannel-authentication-profile-fapi-ciba-certification/)でも次のように言及されています。Authlete すごい！<sup>*</sup>

> _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._

<sup>* DISCLAIMER: 本記事執筆者は [Authlete, Inc.](https://www.authlete.com/) の共同創業者です</sup>


# おわりに

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

[API World](https://apiworld.co/) 2019 を直前に控えた San Jose の宿にて