FAPI Security Profile 2 min read

Pushed Authorization Requests (PAR)

Rather than passing authorization parameters directly in a browser redirect URL (where they're visible and potentially manipulable), consent parameters are first sent server-to-server to the /par endpoint. The Authorization Server returns a short-lived request_uri which is the only thing passed in the browser redirect.

This ensures authorization parameters are never exposed in browser history or server logs.

Signed Request Objects (JAR)

The body of the /par request must be a signed JWT — a JSON Web Signature (JWS). This is a cryptographically signed package of claims that proves:

• Authenticity — the request genuinely came from your registered application
• Integrity — no parameter was modified in transit

See Preparing the Request JWT for the full structure.

PKCE (Proof Key for Code Exchange)

Every authorization request includes a code_challenge derived from a secret code_verifier. When the authorization code is later exchanged for tokens, the code_verifier must be provided. This prevents authorization code interception attacks.

The only supported method is S256 (SHA-256 hash of the verifier).

mTLS (Mutual TLS)

All API requests use mutual TLS — both client and server present certificates during the TLS handshake. Your application must present its transport certificate (issued by the Trust Framework) to authenticate at the network level.

This ensures that even a stolen access token cannot be used without the corresponding private key.