Authlete 3.0 で認可サーバーに複数のFAPIプロファイルを共存可能に

# Authlete 3.0 とは

2025年1月現在、現行で利用・稼働されているAuthleteはほとんどがAuthlete 2系かと思います。

Authlete 3.0 は 2024年11月に公式リリースされて間もないですが、弊社が開発支援している複数のAuthlete利用企業様でもAuthlete 3への移行プロジェクトを開始されています。

https://prtimes.jp/main/html/rd/p/000000017.000024448.html

OID4VCI のサポートや管理画面機能の大幅強化などが特徴的なアップデートですが、v2時点から対応していたFAPI周りの機能についてもv3になってから興味深い機能強化があったので今回の記事ではAuthlete v3でのFAPI設定という観点で記事を書きます。

# Authlete v2 での FAPI 設定

## Scope Attributes

Authlete で FAPI を有効化する方法として Scope Attributes という機能があります。

https://authlete.com/kb/oauth-and-openid-connect/scopes/scope-attributes/

任意のメタデータをスコープに割り当てることができるのですが、Authleteによって事前定義された Key-Valueペアがあります。事前定義は[公式ドキュメント](https://www.authlete.com/kb/oauth-and-openid-connect/scopes/scope-attributes/#predefined-scope-attributes)に記載されており以下表を転載します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3580319/0c18e316-ffe4-868e-9cb4-421de4382b29.png)


Service Owner Console の Token タブ -> Scope で設定できます。

 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3580319/2cbedc97-2f91-0af2-d9b1-c20e215036fe.png)

例えば`fapi:rw` を該当のスコープに設定すると、`accounts` を指定した認可リクエスト、トークンリクエストは FAPI 1.0 Advanced のバリデーションが適用されます。

しかし、これはクライアント単位の設定値ではないため クライアントAは FAPI 1.0, クライアントBは FAPI 2.0 という構成を実現しようとする時は、Scope を分けるしか回避策がありませんでした。

| Scope | Attribute(Key:Value) |
| ---- | ---- |
| accounts | fapi:rw |
| accounts2 | fapi2:sp |


これだと、クライアントに適用するProfileを条件定義して指定できるKeycloak の Client Policiesのような柔軟な機能に劣るなと正直感じていました。

# Authlete v3 での FAPI 設定

Authlete v3 ではどうでしょう。前述の Scope Attributes の機能はv3でも残っています。実際に検証してみたところv2と同じ挙動のようです。

次は、Authlete 3.0 で新たに追加されたFAPI設定の機能を考察します。

## Service Settings

まずは Service Settingsを眺めます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3580319/103dadba-0439-069a-f6ae-172c03e29d8e.png)


### Supported Service Profiles

FAPI をチェックしないと、後述のFAPI Modes は適用されないのでチェックします。公式にも言及があります。

>[IMPORTANT] Supported additional features on top of the base OAuth 2.0 and OpenID Connect. Note that if these features are not enabled in your Authlete server environment, you can’t use them even if they are marked as enabled in the Console. 


### FAPI Modes

サービスレベルで FAPI Profile を指定できます。つまりこの設定を行うとサービスに属するすべてのクライアントに指定したProfileが適用されます。

また、FAPI 1.0 Advanced & FAPI 2.0 Security Profile などコンフリクトするような組み合わせは以下のエラーになって設定はできません。

```json
{
    "resultCode": "A419301",
    "resultMessage": "[A419301] The specified combination of FAPI modes is invalid."
}
```


## Client Settings

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3580319/47251ccb-9eb9-291e-0245-6195e819e759.png)


### FAPI Modes

Service Settings であった FAPI Modes をクライアント単位でも設定できるので、v2で課題だったクライアントAは FAPI 1.0, クライアントBは FAPI 2.0 という構成が容易になりました。

クライアント単位の設定を効かすには以下の注意点があります。

- Service Settings の Supported Service Profiles　にて FAPIがチェックされていること
- Service Settings側のFAPI Modes にチェックが入っていないこと。(Service側の設定が優先されるため。)


また、`Scope Attributes` よりも`FAPI Modes`で指定したプロファイルが優先されることが検証で判明しました。


FAPI Modes : `FAPI 2.0 Security Profile`

Scope Attributes : `fapi:rw` 

という設定を行うとFAPI Modesで設定したFAPI 2.0 SP のバリデーションのみが発生しました。逆パターンも同じでした。


# まとめ

今回の記事では Authlete 3.0 でリリースされた FAPI に関する新機能を紹介しました。従来よりもよりFAPI Profilesの柔軟な設定ができるようになりました。
「既に FAPI 1.0 を実装していて、シームレスにFAPI 2.0 に移行したい」、「あるクライアントはMessage Signingを要求し、あるクライアントは署名無しの Security Profileを適用したい」など様々なシーンで役に立つ機能だと思います。

InstinyはAuthlete活用に特化したIdPの開発及びコンサルティング支援を行っております。現在、Authlete導入を検討されていて、設計・開発を加速させたいとお考えのご企業様はお気軽にお問い合わせください。

また、認証認可に強いエンジニアを積極的に募集しております。