> ## Documentation Index > Fetch the complete documentation index at: https://developers.authlete.com/llms.txt > Use this file to discover all available pages before exploring further. # Validation in FAPI mode > This article discusses how Authlete validates requests in FAPI 1.0 Baseline/Advanced mode for Financial-grade API Security Profiles. ## 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](https://openid.net/specs/openid-financial-api-part-1-1_0-final.html)) and FAPI 1.0 Advanced ([Financial-grade API Security Profile 1.0 - Part 2: Advanced](https://openid.net/specs/openid-financial-api-part-2-1_0.html)). 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](https://tools.ietf.org/html/bcp212#section-7.2) > at [BCP 212](https://tools.ietf.org/html/bcp212) > (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](https://medium.com/@darutk/financial-grade-api-fapi-explained-by-an-implementer-d09fcf2ff932)