FAPI 2.0: what compliance actually requires you to build

“FAPI-aligned” appears in almost every Gulf open banking summary, always as a passing clause and never with any indication of what it costs to implement. It is not a badge you apply for. It is a list of requirements, and several of them will invalidate things your OAuth implementation currently does.

Requirements below are read from the FAPI 2.0 Security Profile, published by the OpenID Foundation. Checked 27 July 2026. Where wording matters, the specification’s own “shall” language governs — read it rather than relying on this summary.

Sender-constrained tokens, without exception

An authorization server shall only issue sender-constrained access tokens, using either mutual TLS or DPoP. Clients must support one or both.

This is the requirement with the largest blast radius. A bearer token is usable by whoever holds it. A sender-constrained token is bound to a key the legitimate client possesses, so a stolen token is useless on its own.

On mTLS that means certificate provisioning, rotation and revocation become operational concerns, and your TLS-terminating layer has to pass the client certificate through to the application. On DPoP it means proof-of-possession JWTs on every request, and the clock-skew handling that comes with them.

Neither is a configuration change. Both are infrastructure.

Pushed Authorization Requests, mandatory

The authorization server shall reject authorization requests sent without PAR, and clients shall use it.

The familiar pattern — build a long authorization URL with parameters in the query string and redirect the browser to it — is not permitted. Instead the client POSTs the request directly to the server, receives a request_uri, and the browser is then sent to the authorization endpoint with only client_id and request_uri.

Parameters never traverse the browser, so they cannot be tampered with in transit or leak through referrer headers and logs. It also adds a back-channel round trip before every authorization, which changes your latency budget.

If you have seen signed request objects in a market’s documentation instead, that is FAPI 1.0 Advanced language — the older profile achieved similar protection by having the client sign a JWT request object. Establish which profile your market mandates before building. The two are not interchangeable, and migrating means replacing the request-object signing path with PAR and moving response validation to JARM.

PKCE with S256, and a 60-second code lifetime

PKCE is required with S256 as the code challenge method; plain is not acceptable. Authorization codes are limited to a 60-second maximum lifetime and cannot be reused.

Sixty seconds is short enough to matter. Any flow that parks a code while a user completes something else, or that relies on a slow server-to-server hop before redemption, will fail intermittently — and it will look like a network problem rather than a policy one.

The `iss` check that prevents mix-up attacks

The authorization server shall return an iss parameter in the authorization response, and the client shall check it.

This defends against mix-up attacks, where a client integrated with several authorization servers is tricked into sending a code issued by one to another. It costs a few lines, it is easy to omit because everything works without it, and omitting it is a real vulnerability rather than a theoretical one.

Client authentication

Clients must be authenticated using mutual TLS or private_key_jwt. Shared client secrets are out.

Combined with sender-constraining, this is where teams find the real cost: key material management becomes a first-class part of the system, in every environment, with rotation that does not require downtime.

What is prohibited

Refresh token rotation, except in extraordinary circumstances. Worth flagging, because rotation is a widely recommended default elsewhere.
Redirect URIs using the http scheme, except for native clients.
Resource owner password credentials grants.
Reusing authorization codes.
Open redirectors.
The none signing algorithm.

Cryptographic floor

Signing must use PS256, ES256 or EdDSA (Ed25519). RSA keys must be at least 2048 bits, elliptic curve keys at least 224 bits. All endpoints must be TLS-protected, TLS 1.2 or later.

RS256 is not on the permitted list, and a great many existing implementations default to it. That alone will force a change in most systems arriving from a non-FAPI background.

What this adds up to

Read as a whole, FAPI 2.0 assumes an attacker who can intercept a browser redirect, steal a token, or impersonate a client — and removes the value of each. Nothing in it is exotic, but very little of it is default behaviour in an ordinary OAuth stack.

For a team estimating the work, the load sits in three places, roughly in order of effort:

Key and certificate management. Provisioning, rotation, revocation, across every environment. Operational, ongoing, and the part consistently underestimated.
PAR. A structural change to the authorization flow, not a parameter.
Algorithm and lifetime constraints. Individually small, collectively a sweep through every place your system assumes something about tokens.

The open question for the Gulf

Which profile version each market mandates is not settled by this article, deliberately.

Saudi documentation refers both to mandatory PAR, which points at FAPI 2.0, and to signed request objects, which is FAPI 1.0 Advanced language. Both cannot describe one profile version, and the difference is a real migration rather than a detail. Anyone scoping this work needs the answer from the published Saudi standard itself.

The UAE position is also unestablished here — whether FAPI is mandated at all, and if so which version. The UAE pricing analysis covers what that market’s API Hub costs to use; the security profile it requires is a separate question and not one this piece answers.

Sources

FAPI 2.0 Security Profile, OpenID Foundation. Checked 27 July 2026.

Requirements are summarised, not reproduced. Where implementation depends on exact wording, read the specification — its normative “shall” statements are what a certification body will test against, and a summary is not a substitute.