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



3. Redirect URI scheme
Baseline
The redirect_uri should use the "https" scheme.
Advanced
same as Baseline


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



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


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.



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.




16. Signing Algorithm  of Response JWT
Baseline
-
Advanced
The metadata of a client, authorization_signed_response_alg, must be PS256 or ES256. 



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



How did we do with this article?