Validation in FAPI mode


Preface


Authlete 2.0+ provide FAPI mode, which enables to issue and validate tokens based on the FAPI Part 1 & 2 security profiles. This document describes the validation scheme of Authlete's FAPI mode.

Each "RO" and "RW" represents as follow:
RO
Read Only mode. 
With this mode, Authlete will issue and validate tokens based on Financial-grade API - Part 1: Read Only API Security Profile.
RW
Read and Write mode. 
With this mode, Authlete will issue and validate tokens based on Financial-grade API - Part 2: Read and Write API Security Profile.




 Authorization Endpoint


1. response_type parameter 
RO
-
RW
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
RO
The redirect_uri value must be specified. 
RW
same as RO



3. Redirect URI scheme
RO
The redirect_uri should use the "https" scheme.
RW
same as RO


4. Redirect URI validation
RO
 This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider.
RW
same as RO



5. state parameter
RO
The state parameter is required when the scope parameter does not include "openid" scope value.
RW
same as RO



6. nonce parameter
RO
The nonce request parameter is required if it is desired to obtain a persistent identifier of the authenticated user.
RW
same as RO


7. Request Object
RO
-
RW
The signed request object is required, which means that request or request_uri parameter shall be in authorization requests.

8. Request Object Signature
RO
-
RW
The request object must be signed.



9. Request Parameters outside Request Object
RO
-
RW
All parameters outside the requet object must be included inside the request object.



10. exp claim in Request Object
RO
-
RW
The request object must contain an exp claim.



11. aud claim in Request Object
RO
-
RW
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
RO
-
RW
PS256 or ES256



13. code_challenge parameter
RO
The code_challenge parameter is required.
RW
The code_challenge parameter is required when the client type is public.



14. code_challenge_method parameter
RO
The code_challenge_method value must be S256.
RW
The code_challenge_method value must be S256 when the client type is public.



15. ACR 
RO
-
RW
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
RO
-
RW
The metadata of a client, authorization_signed_response_alg, must be PS256 or ES256. 



17. Signing Algorithm of ID Token
RO
-
RW
The metadata of a client, id_token_signed_response_alg, must be PS256 or ES256. 




Token Endpoint


18.  Client Authentication Options
RO
  • tls_client_auth
  • self_signed_tls_client_auth
  • client_secret_jwt
  • private_key_jwt
RW
  • tls_client_auth
  • self_signed_tls_client_auth
  • private_key_jwt

19. Signing Algorithm of Client Assertion
RO
-
RW
PS256 or ES256

20. Key Size of Client Assertion
RO
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.
RW
same as RO



21. Signing Algorithm of ID Token
RO
-
RW
The metadata of a client, id_token_signed_response_alg, must be PS256 or ES256. 



22. Holder-of-Key Method
RO
-
RW
Either OAUTB (Token Binding) or MTLS (Certificate Binding) must be used for Holder-of-Key method.




User Info Endpoint


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

Reference



How did we do with this article?