Skip to main content

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-
AdvancedThe 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
BaselineThe redirect_uri value must be specified. 
Advancedsame 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
BaselineThe redirect_uri should use the “https” scheme.
Advancedsame 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
BaselineThis URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider.
Advancedsame 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
BaselineThe state parameter is required when the scope parameter does not include “openid” scope value.
Advancedsame as Baseline
6. nonce parameter
BaselineThe nonce request parameter is required if it is desired to obtain a persistent identifier of the authenticated user.
Advancedsame 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-
AdvancedThe signed request object is required, which means that request or request_uri parameter shall be in authorization requests.
8. Request Object Signature
Baseline-
AdvancedThe request object must be signed.
9. Request Parameters outside Request Object
Baseline-
AdvancedAll parameters outside the requet object must be included inside the request object.
10. exp claim in Request Object
Baseline-
AdvancedThe request object must contain an exp claim.
11. aud claim in Request Object
Baseline-
AdvancedThe 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-
AdvancedPS256 or ES256
13. code_challenge parameter
BaselineThe code_challenge parameter is required.
AdvancedThe code_challenge parameter is required when the client type is public.
14. code_challenge_method parameter
BaselineThe code_challenge_method value must be S256.
AdvancedThe 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-
Advancedacr 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-
AdvancedThe 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-
AdvancedThe 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-
AdvancedPS256 or ES256
20. Key Size of Client Assertion
BaselineA 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.
Advancedsame as Baseline
21. Signing Algorithm of ID Token
Baseline-
AdvancedThe metadata of a client, id_token_signed_response_alg, must be PS256 or ES256. 
22. Mechanism for sender-constrained access tokens
Baseline-
AdvancedSupport MTLS (Certificate Binding) as mechanism for sender-constrained access tokens.

User Info Endpoint

23. Signing Algorithm of User Info Response
Baseline-
AdvancedThe algorithm must be either PS256 or ES256 when a user info response is signed.

Reference