Configure FAPI Compliance

To help customers configure their Auth0 tenant to adhere to one of the Financial-grade API (FAPI) profiles, the Application model includes a compliance_level property that can be set to one of three values:

  • null or undefined: No compliance level is required. This is the default.

  • fapi1_adv_mtls_par: The customer would like this client to behave in accordance with the FAPI1 Advanced profile using mTLS and PAR.

  • fapi1_adv_pkj_par: The customer would like this client to behave in accordance with the FAPI1 Advanced profile using Private Key JWT and PAR.

Use Management API to set the compliance_level property with a POST or PATCH request: 

curl --location --request PATCH 'https://$tenant/api/v2/clients/$client_id' \
  --header 'Authorization: Bearer $management_access_token' \
  --header 'Content-Type: application/json' \
  --data '{
    "compliance_level": "fapi1_adv_mtls_par"
}'

Was this helpful?

/

To return the compliance_level property, use a GET request:

curl --location 'https://$tenant/api/v2/clients/$client_id \
  --header 'Authorization: Bearer $management_access_token'

Was this helpful?

/

Complying with a FAPI profile requires a number of configuration changes. Setting the compliance_level ensures that no authorization request can succeed unless the request and the configuration is compliant with the selected standard.

For example, both the fapi1_adv_pkj_par and fapi1_adv_mtls_par compliance levels require PAR. If either of these compliance levels are selected, PAR is required regardless of the value of the require_pushed_authorization_requests setting. Attempting an authorization without using PAR results in the following error response:

{
  “error”: “invalid_request”,
  “error_description”: “Pushed Authorization Requests are required by the configured compliance level” 
}

Was this helpful?

/

In some cases, setting a compliance level also changes Auth0’s behavior. For example, both the fapi1_adv_pkj_par and fapi1_adv_mtls_par compliance levels cause Auth0 to include a s_hash claim in the returned ID token containing a SHA256 hash of the state value. This allows the ID tokens to act as a detached signature.

The following tables summarize the additional validation rules and changes to Auth0’s behavior that each compliance level enables:

Validation fapi1_adv_pkj_par fapi1_adv_mtls_par
Prevents the use of access tokens in the URL query when calling /userinfo. Access tokens must be placed in the Authorization header instead. Y Y
Requires PAR. Y Y
Requires PKCE with the S256 challenge method. Y Y
Prevents the use of wildcards in the allowed callbacks on a client. Y Y
Enforces the use of JAR. Y Y
Ensures the JAR payload is signed using the PS256 algorithm. Y Y
Ensures the JAR payload contains the nbf claim and it is no longer than 60 minutes in the past. Y Y
Ensures the JAR payload contains the exp claim and that it is no more than 60 minutes after the nbf claim. Y Y
Ensures the client has set the oidc_conformant property to true. Y Y
Requires the use of Private Key JWT for client authentication. Y N
Requires the use of mTLS for client authentication. N Y

Auth0 updated behavior fapi1_adv_pkj_par fapi1_adv_mtls_par
Adds s_hash claim to ID tokens. Y Y
When the profile scope is requested, the update_at claim contains an OIDC Conformant unix timestamp rather than a string. Y Y
Returns only OIDC conformant error codes. In some cases, Auth0 may return additional error codes, but enabling this compliance level ensures that Auth0 only uses error codes defined in the OpenID standards. Y Y

Learn more