Financial-grade API Security Profile 1.0 - Part 1: Baseline   5.2.2 Authorization serverメモ


* Financial-grade API Security Profile 1.0 - Part 1: Baseline   5.2.2. Authorization serverの章についての個人的メモ。
* ほぼ訳しただけ。

## Financial-grande API とは

* OAuth2.0やOpenID Connectをベースとした技術仕様。
* パート1のBaselineとパート2のAdvancedの2パートを提供している。
  * BaselineはAdvancedに包含されている。
  * より高いレベルのセキュリティを必要とする、機密性の高い情報のやり取りを行うAPIはAdvancedへの準拠が望ましいとのこと。

### 5.2 Baseline security provisions / 5.2.2 Authorization server

* **コンフィデンシャルクライアントをサポートしなければならない**
  * コンフィデンシャルクライアント
    * クライアントシークレットをセキュアに管理できる、もしくは他の方法でセキュアなクライアント認証可能なクライアント
    * Webアプリ

* **パブリッククライアントをサポートすべきである**
  * パブリッククライアント
    * クライアントシークレットをセキュアに管理できず、他の方法でもセキュアにクライアント認証できないクライアント
    * モバイルアプリ、SPA、デスクトップ

* **共有鍵を用いる場合、OIDC Core 16.19 の要求事項を満たすクライアントシークレットを提供しなければならない**
  * 共有鍵
    * 署名処理などで対称鍵系アルゴリズムを用いる場合、OIDC Coreでは、クライアントシークレットから算出した値
  * 算出元となるクライアントシークレットのエントロピーがアルゴリズムが要求する値より低い場合、アルゴリズム強度が低下することから、利用アルゴリズムに対してクライアントシークレットが十分なエントロピーを持つことを要求している。

* **Confidential クライアントを次のいずれかの方式で認証しなければならない**
  1. Mutual TLS for OAuth Client Authentication
  2. `client_secret_jwt` もしくは `private_key_jwt`

* **`private_key_jwt` を用い、JWT の署名に RSA アルゴリズムを用いる場合、キーサイズは 2048 ビット以上である必要がある**

* **楕円曲線アルゴリズムを用いる場合、キーサイズは 160 ビット以上である必要がある**

* **PKCEリクエストパラメーターを指定する必要がある**
  * コードチャレンジメソッドは `S256`とする。

* **リダイレクト URI は必ず事前登録する必要がある**

* **認可リクエストには 必ず`redirect_uri` パラメータを指定する必要がある**
* **`redirect_uri` は事前登録されたものと完全一致しなければならない。**

* **適切なLevel of Assuranceのユーザー認証をしなければならない**
  * [X.1254](https://www.itu.int/rec/T-REC-X.1254)（Entity authentication assurance framework）で定義

* **未認可スコープはユーザーの承認を明示的に得なければならない**

* **使用済み認可コードは拒絶しなければならない**

* **RFC 6749 の 4.1.4 に準拠するトークンレスポンスを返さなければならない**

* **リクエストがフロントチャネルを経由し、完全性が保護されていない場合、付与されたスコープリストをアクセストークンと共に返さなければならない**
  * 完全性の保護：リクエストオブジェクト（OIDC Core [Section 6](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests) または [JAR](https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/)）を使用している。

* **認可コード、アクセストークン、リフレッシュトークンは十分なエントロピーを持ち、推測不可能な値であること**

* **認可処理中に付与する権限の詳細情報をユーザーに明示すべきである**
  * スコープの目的や詳細情報など。

* **クライアントに発行したアクセストークンとリフレッシュトークンをユーザーが取り消しできる仕組みを提供すべきである**
  * PKI（Public Key Infrastructure）におけるCertificate Revocation List(CRL)や Online Certificate Status Protocol(OCSP)に相当する仕組みを実装・運用する。

* **クライアント識別子の指定方法を複数持つクライアント認証方式において、クライアント識別子が複数含まれ、それらが一致しない場合、`invalid_client` エラーを返さなければならない**

* **リダイレクト URI のスキームは `https` でなければならない**
  * 対ネイティブアプリ。カスタムスキームを使用不可。

* **アクセストークンが送信者限定でない限り、有効期間は 10 分以内でなければならない**
  * 送信者限定＝アクセストークンがクライアント証明書に紐付いていること。

* **ディスカバリーエンドポイントをサポートしなければならない**
  * 他の方法で（認可エンドポイントなどの）ディスカバリーメタデータを配布してはならない。

#### 5.2.2.1. Returning authenticated user's identifier

ユーザーの一意識別子が要求されている場合、認可サーバーは次の要求事項に従わなければならない。

* OpenID Connect の認可エンドポイントへのリクエスト方法をサポートしなければならない
* OIDC Core の 3.1.2.2 に従い、認証リクエストを検証しなければならない
* OIDC Core の 3.1.2.2 および3.1.2.3 に従いユーザー認証しなければならない
* 認証結果に応じて、OIDC Core の3.1.2.4と3.1.2.5に従って認証レスポンスを提供しなければならない
* OIDC Core の 3.1.3.2 に従ってトークンリクエストの検証を行わなければならない
* 要求された `scope`パラメータ に `openid` が含まれていた場合、認証されたユーザーを示す `sub` クレームと、任意で `acr` クレームを含む ID トークン発行し、トークンレスポンスに含めなければならない

#### 5.2.2.2. Client requesting openid scope

* クライアントが `openid` スコープを要求している場合、認可サーバーは `nonce` パラメーターを要求しなければならない

#### 5.2.2.3. Clients not requesting openid scope

* クライアントが `openid` スコープを要求していない場合、認可サーバーは`state` パラメーターを要求しなければならない

### 

## 参考情報

* [FAPI 1.0 Part 1 and Part 2 are now Final Specifications](https://openid.net/2021/03/12/fapi-1-0-part-1-and-part-2-are-now-final-specifications/)

* [Financial-grade API Security Profile 1.0 - Part 1: Baseline](https://openid.net/specs/openid-financial-api-part-1-1_0.html#authorization-server)