The FAPI 2.0 profile in your tenant
FAPI 2.0 is a security profile for high-value APIs, such as banking. It does not add new protocols: it makes a set of protections this tenant already offers mandatory, together.
The same controls apply to BTL's own organization under BTL Admin, OAuth Management.
What the profile enforces
| Rule | What happens otherwise |
|---|---|
A confidential client that authenticates with private_key_jwt, whose assertion's aud is the issuer as a single string, or with a certificate over mutual TLS | invalid_client; another audience, such as the endpoint URL, or a list of audiences is refused |
Every authorization request is pushed to /oauth/par | The request returns invalid_request (pushed_request_required) |
Only the code response type, with PKCE S256 | unauthorized_client or invalid_request |
| Every access token is sender-constrained: each token request carries a DPoP proof, or the client receives certificate-bound tokens | invalid_dpop_proof (dpop_proof_required) |
| Client assertions, request objects and DPoP proofs use PS256, ES256 or EdDSA | Refused with the reason fapi_algorithm, or request_object_alg_not_allowed |
| The client's access token and ID token managers sign with PS256, ES256 or EdDSA | The request fails before sign-in with server_error (fapi_signing_alg) |
| Authorization codes last at most 60 seconds | A shorter Flow Policy lifetime still applies |
| Refresh tokens do not rotate: a refresh returns a new access token and keeps the same refresh token | |
| Redirect URIs use https | The client cannot be saved |
Every response already names its issuer in iss, and codes are single use.
Setting up a client
In Clients, choose Security profile, FAPI 2.0. Saving checks the client against the profile and names the first setting that still needs to change: make it confidential, set Client authentication to private_key_jwt and register its public keys in Access Token Management, allow only the code response and the authorization code, refresh token and client credentials grants, keep PKCE required, use https redirect URIs, and move its managers to a PS256, ES256 or EdDSA key in Key Management. New tenants sign ID tokens with RS256, so the ID token manager usually needs a new key. Flow Policy must keep pushed requests and DPoP allowed.
Every client at once
In Flow Policy, Profile for every client set to FAPI 2.0 applies the rules to every client except the built-in Token Decoder. It is refused while any client does not meet the profile (fapi_clients_not_ready), so set the profile on each client first. While it is on, a client that would stop meeting it cannot be saved, and pushed requests or DPoP cannot be turned off. A point-in-time restore keeps the profile on a client or tenant that chose it after the restore point.
What is not covered
Signed authorization responses (JARM) are available with any client but not required by the profile. The tenant has not been certified with the OpenID Foundation's conformance suite.