For Authlete 2.x documentation, see 2.x version.
概要
本ドキュメントでは、FAPI 2.0 Security Profileで規定される認可コードフローの概要について解説します。また、それに準拠するためのサービス・クライアントの設定方法についても解説します。FAPI 2.0 Security Profile の機能は Authlete 2.3 以降で利用可能です。
はじめに
FAPI 2.0 Security Profile で規定される認可コードフローは以下のようになります。
Authorization Code Flow in FAPI 2.0 Security Profile
1. Pushed Authorization リクエスト
最初に、クライアントは認可サーバーの pushed authorization request エンドポイントに対してリクエストを送信します。これにより、送信された認可リクエストパラメーター群が認可サーバーに登録されます。FAPI 2.0 Security Profile の要請により、認可リクエストパラメーターにはいくつかの要求事項が課されます (response_type=code 等)。また、クライアント認証方法についても mutual TLS authenticationまたは private_key_jwtのいずれかを用いることが要求されます。本ドキュメントではクライアント認証方法として private_key_jwt を用いることに注意してください。2. Pushed Authorization レスポンス
リクエストが正常に処理された場合、pushed authorization request エンドポイントはリクエスト URI (request_uri) を含むレスポンスを返却します。3. 認可リクエスト
クライアントはリクエスト URI (request_uri) を含む認可リクエストを認可サーバーの認可エンドポイントに送信します。このステップはユーザーエージェントを通じて行われます。4. 認可レスポンス
リクエストが正常に処理された場合、認可エンドポイントから認可コードを含むレスポンスが返却されます。これを受けて、ユーザーエージェントはクライアントのリダイレクト URI へリダイレクトされます。5. トークンリクエスト
クライアントは認可コードを含めてトークンエンドポイントへリクエストを送信します。FAPI 2.0 Security Profile による要請から、トークンエンドポイントは mutual TLS または DPoP によって送信者制限されたアクセストークンを発行する必要があります。本ドキュメントでは送信者制限のメカニズムとして DPoP を利用することにします。また、pushed authorization request エンドポイントと同様にトークンエンドポイントでも **private_key_jwt **によってクライアント認証を行うことに注意してください。6. トークンレスポンス
リクエストが正常に処理された場合、トークンエンドポイントはアクセストークンを含むレスポンスを返却します。7. API リクエスト
クライアントは発行されたアクセストークンとその所有者証明 (本ドキュメントの場合、DPoP proof JWT) を利用して、リソースエンドポイントへアクセスします。FAPI 2.0 Security Profile スコープ
Authlete 2.3 以降、FAPI 2.0 Security Profile のために新たなスコープ属性が導入されました。属性の定義は以下の通りです。| 属性のキー | 属性の値 |
|---|---|
| fapi2 | sp |

サービスを FAPI 2.0 Security Profile 準拠に設定する方法
サービスを FAPI 2.0 Security Profile 準拠にするためには、以下のよう設定にしてください。| プロパティ | 説明 |
|---|---|
| サポートする認可種別 | **AUTHORIZATION_CODE **含める。 |
| サポートする応答種別 | **CODE **を含める。 |
| サポートするプロフィール群 | **FAPI **含める。 |
| iss レスポンスパラメーター | 含めるを選択。 |
| トークンエンドポイントの URI | 認可サーバーのトークンエンドポイントの URI を設定。 |
| サポートするクライアント認証方式 | **PRIVATE_KEY_JWT **を選択。 |
| nbf クレーム | 必須を選択。 |
| オーディエンス確認 | 実行するを選択。 |
| アクセストークン署名アルゴリズム | 注意:この設定は JWT 形式のアクセストークンを発される場合のみ必要。PS256、ES256、EdDSA のいずれかを選択。 |
| サポートするスコープ | FAPI 2.0 Security Profile スコープを作成。 |
| JWK セットの内容 | 注意:この設定は “JWK セットの内容” を利用する場合のみ必要。必要な JWK (e.g. JWT アクセストークンの署名用鍵) を含む JWK セットを設定。 |
| JWK セットエンドポイントの URI | 注意:この設定は “JWK セットエンドポイントの URI” を利用する場合のみ必要。必要な JWK (e.g. JWT アクセストークンの署名用鍵) を含む JWK セットを指す URI を設定。https で始まる URI を設定すること。 |
クライアントを FAPI 2.0 Security Profile 準拠に設定する方法
クライアントを FAPI 2.0 Security Profile 準拠にするためには、以下のよう設定にしてください。| プロパティ | 説明 |
|---|---|
| クライアントタイプ | CONFIDENTIAL を選択。 |
| 認可種別 | AUTHORIZATION_CODE 含める。 |
| 応答種別 | CODE を含める。 |
| リダイレクト URI | リダイレクト URI を少なくとも一つ作成。 |
| クライアント認証方式 | PRIVATE_KEY_JWT を選択。 |
| アサーション署名アルゴリズム | PS256、ES256、EdDSA のいずれかを選択。 |
| ID トークン署名アルゴリズム | 注意:この設定は署名された ID トークンが発行される場合のみ必要。PS256、ES256、EdDSA のいずれかを選択。 |
| ID トークン暗号化アルゴリズム | 注意:この設定は暗号化された ID トークンが発行される場合のみ必要。RSA1_5 以外を選択。 |
| JWK セットの内容 | 注意:この設定は “JWK セットの内容” を利用する場合のみ必要。必要な JWK (e.g. クライアントアサーションの署名検証用鍵) を含む JWK セットを設定。 |
| JWK セットの URI | 注意:この設定は “JWK セットの URI” を利用する場合のみ必要。必要な JWK (e.g. クライアントアサーションの署名検証用鍵) を含む JWK セットを指す URI を設定。https で始まる URI を設定すること。 |
API コールテスト
このセクションでは、FAPI 2.0 Security Profile で規定される認可コードフローにおいて、認可サーバーから Authlete API に対して送信される API コールを実際にシミュレートします。1. /pushed_auth_req API
FAPI 2.0 Security Profile で規定される認可コードフローにおいて、クライアントが認可サーバーの pushed authorization request エンドポイントに対して正常なリクエストを送信したとします。FAPI 2.0 Security Profile, Requirements for Clients における要求事項により、クライアントから認可サーバーへのリクエストは以下のようになります。2. /auth/authorization API
pushed authorization request エンドポイントからリクエスト URI が発行された後、クライアントは認可サーバーの認可エンドポイントに対して当該リクエスト URI を含めた認可リクエストを送信します。 以下はリクエストの例です。3. /auth/authorization/issue API
認可サーバーが /auth/authorization API から正常レスポンスを受けた後、エンドユーザーはブラウザ上でクライアントを認可/拒否し、その結果が認可サーバーに伝達されます。それを受けて、認可サーバーは Authlete の /auth/authorization/issue API をコールします。以下の curl コマンドは、認可サーバーから Authlete の /auth/authorization/issue API に対するリクエストをシミュレートしたものです。4. /auth/token API
認可エンドポイントから認可コードを含むレスポンスを受けた後、クライアントは認可サーバーのトークンエンドポイントに対して以下のようなリクエストを送ります。- private_key_jwt によって認証される
- DPoP proof JWT をリクエストに含めなければならない (DPoP proof JWT は PS256、ES256、EdDSA のいずれかで署名されている必要がある)
その後、認可サーバーは Authlete の /auth/token API をコールします。以下の curl コマンドは、認可サーバーから Authlete の /auth/token API に対するリクエストをシミュレートしたものです。