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

Financial-grade API (FAPI), explained by an implementer

Basic OAuth/OIDC Flows

Advanced Flows

Protocol Extensions

Compliance Profiles

Verifiable Credentials

Preface

Authorization Endpoint

Token Endpoint

User Info Endpoint

Reference

​Preface

​ Authorization Endpoint

​Token Endpoint

​User Info Endpoint

​Reference

Preface

Authorization Endpoint

Token Endpoint

User Info Endpoint

Reference