Validation in FAPI mode
Preface
Authlete 2.0+ provides Financial-grade API (FAPI) mode, which enables to issue and validate tokens based on FAPI 1.0 Baseline (Financial-grade API Security Profile 1.0 - Part 1: Baseline) and FAPI 1.0 Advanced (Financial-grade API Security Profile 1.0 - Part 2: Advanced). This document describes how Authlete validates requests in FAPI 1.0 Baseline/Advacned mode.
Authorization Endpoint
1. response_type parameter
|
|
| Baseline |
- |
| Advanced |
The value must be either “code id_token” or “code id_token token” unless the response_mode value is “query.jwt”, “fragment.jwt”, “form_post.jwt” or “jwt”. |
2. redirect_uri parameter
|
|
| Baseline |
The redirect_uri value must be specified. |
| Advanced |
same as Baseline |
The redirect_uri value is required when the scope parameters include “openid”, according to OpenID Connect Core, not Financial-grade API.
3. Redirect URI scheme
|
|
| Baseline |
The redirect_uri should use the “https” scheme. |
| Advanced |
same as Baseline |
You cannot use custom schemes in FAPI 1.0 mode. Thus, you may use the method described in 7.2 Claimed “https” Scheme URI Redirection
at BCP 212
(OAuth 2.0 for Native Apps) when you want to handle the redirect sequences only in native apps.
4. Redirect URI validation
|
|
| Baseline |
This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider. |
| Advanced |
same as Baseline |
The exact match is required when the scope parameters include “openid” according to OpenID Connect Core, not Financial-grade API.
5. state parameter
|
|
| Baseline |
The state parameter is required when the scope parameter does not include “openid” scope value. |
| Advanced |
same as Baseline |
6. nonce parameter
|
|
| Baseline |
The nonce request parameter is required if it is desired to obtain a persistent identifier of the authenticated user. |
| Advanced |
same as Baseline |
Authlete considers “if it is desired to obtain a persistent identifier of the authenticated user” as “if an id_token is requested”. Therefore, the nonce parameter is required “when the response_type request parameter includes id_token” or “when the response_type includes code and the scope parameter includes openid.”
7. Request Object
|
|
| Baseline |
- |
| Advanced |
The signed request object is required, which means that request or request_uri parameter shall be in authorization requests. |
8. Request Object Signature
|
|
| Baseline |
- |
| Advanced |
The request object must be signed. |
9. Request Parameters outside Request Object
|
|
| Baseline |
- |
| Advanced |
All parameters outside the requet object must be included inside the request object. |
10. exp claim in Request Object
|
|
| Baseline |
- |
| Advanced |
The request object must contain an exp claim. |
11. aud claim in Request Object
|
|
| Baseline |
- |
| Advanced |
The request object must contain an aud claim that is, or that is an array containing, the OP’s Issuer Identifier URL. |
12. Signing Algorithm of Request Object
|
|
| Baseline |
- |
| Advanced |
PS256 or ES256 |
13. code_challenge parameter
|
|
| Baseline |
The code_challenge parameter is required. |
| Advanced |
The code_challenge parameter is required when the client type is public. |
14. code_challenge_method parameter
|
|
| Baseline |
The code_challenge_method value must be S256. |
| Advanced |
The code_challenge_method value must be S256 when the client type is public. |
The code_challenge_method value must be S256 because authorization servers treat the code with plain when the code_challenge_method is not specified.
15. ACR
|
|
| Baseline |
- |
| Advanced |
acr claim is required as an essential claim. A client must use the claims request parameter, pass JSON as its value, and include {“essential":true} inside the JSON. |
This validation won’t be executed in OPEN_BANKING mode.
16. Signing Algorithm of Response JWT
|
|
| Baseline |
- |
| Advanced |
The metadata of a client, authorization_signed_response_alg, must be PS256 or ES256. |
Request response will be formated in JSON when JARM is used.
17. Signing Algorithm of ID Token
|
|
| Baseline |
- |
| Advanced |
The metadata of a client, id_token_signed_response_alg, must be PS256 or ES256. |
Token Endpoint
18. Client Authentication Options
|
|
| Baseline |
- tls_client_auth
- self_signed_tls_client_auth
- client_secret_jwt
- private_key_jwt
|
| Advanced |
- tls_client_auth
- self_signed_tls_client_auth
- private_key_jwt
|
19. Signing Algorithm of Client Assertion
|
|
| Baseline |
- |
| Advanced |
PS256 or ES256 |
20. Key Size of Client Assertion
|
|
| Baseline |
A key of size 2048 bits or larger is required if RSA algorithms are used for the client authentication. A key of size 160 bits or larger is required if elliptic curve algorithms are used for the client authentication. |
| Advanced |
same as Baseline |
21. Signing Algorithm of ID Token
|
|
| Baseline |
- |
| Advanced |
The metadata of a client, id_token_signed_response_alg, must be PS256 or ES256. |
22. Mechanism for sender-constrained access tokens
|
|
| Baseline |
- |
| Advanced |
Support MTLS (Certificate Binding) as mechanism for sender-constrained access tokens. |
User Info Endpoint
23. Signing Algorithm of User Info Response
|
|
| Baseline |
- |
| Advanced |
The algorithm must be either PS256 or ES256 when a user info response is signed. |
Reference
