FAPI (Financial-grade API)

FAPI is not a new protocol but a security profile that mandates specific, stricter implementations of OAuth 2.0 and OpenID Connect. It is defined by the OpenID Foundation's FAPI Working Group. The profile is divided into two parts:

• FAPI 1.0 Advanced (Read/Write API): For high-value transactions (e.g., payments, account modifications). Requires the strongest security controls, including sender-constrained tokens and PAR.
• FAPI 1.0 Baseline (Read-Only API): For accessing sensitive data (e.g., account balances). Provides a high-security baseline that is a prerequisite for the Advanced profile. The goal is to create a standardized, interoperable, and highly secure API security layer that can be independently certified.

A cornerstone of FAPI security is moving beyond simple bearer tokens. In standard OAuth, anyone in possession of a bearer token can use it. FAPI mandates sender-constrained tokens, where the client must prove possession of a key to use the token. The two primary methods are:

• Mutual TLS (mTLS) for OAuth: The client presents a TLS certificate during the TLS handshake with the resource server. The access token is bound to the certificate's thumbprint (cnf claim). The resource server verifies the client's presented certificate matches the binding.
• Demonstration of Proof-of-Possession (DPoP): The client signs a JWT containing the token's thumbprint and other data with a private key. This DPoP proof is sent with the API call. The resource server validates the signature using the public key bound to the token. This prevents token replay if the token is stolen from a client's storage.

FAPI requires the use of Pushed Authorization Requests (PAR, RFC 9126) for the Authorization Code flow. Instead of sending all authorization request parameters via the user's browser (front-channel), the client pushes them directly to the authorization server's PAR endpoint via a secure back-channel request (authenticated with private_key_jwt). Process:

1. Client sends a complete authorization request (including code_challenge for PKCE) to the PAR endpoint.
2. Authorization server validates the request, stores it, and returns a unique request_uri.
3. Client redirects the user's browser to the authorization endpoint with only the client_id and request_uri. Benefits:

• Prevents parameter tampering and injection via the browser.
• Allows for full request validation before user interaction.
• Enables the use of long, complex parameters without URL length limits.

FAPI enforces strong client authentication to the authorization server, moving beyond simple client secrets. The required method is private_key_jwt client authentication. How it works:

• The client registers a public key (in JWK format) with the authorization server.
• For authentication (e.g., at the token endpoint), the client creates a JWT (the client assertion) signed with its corresponding private key.
• This JWT includes claims like iss (client ID), sub (client ID), aud (authorization server URL), and jti (unique token ID).
• The authorization server validates the JWT's signature using the registered public key and the claims. This method is highly secure as it doesn't rely on a shared secret and provides non-repudiation. It is used for all back-channel communications, including the PAR endpoint and token endpoint.

FAPI specifies precise cryptographic algorithms to ensure interoperability and eliminate weak options. Key requirements include:

• Signing Algorithms: Mandates PS256 (RSA PSS) or ES256 (ECDSA) for JWTs (ID tokens, client assertions, DPoP proofs). Insecure algorithms like none or HS256 are prohibited.
• Encryption: For sensitive data, requires JWE encryption using strong algorithms like RSA-OAEP for key encryption and A256GCM for content encryption.
• TLS: Mandates TLS 1.2 or higher with specific cipher suites, and often requires mutual TLS (mTLS) for certain endpoints.
• Key Management: Clients and servers must securely generate, store, and rotate cryptographic keys. The use of Hardware Security Modules (HSMs) or secure cloud key management services is strongly encouraged for protecting private keys, especially in production financial environments.

For AI agents performing tool calling and API execution, integrating with FAPI-protected services requires a specialized security architecture:

• Credential Management: The agent's platform must securely store and manage the client's private key for private_key_jwt authentication, never exposing it in prompts or logs.
• Dynamic Proof Generation: The agent must be able to dynamically generate signed JWTs (client assertions, DPoP proofs) for each authenticated request, which requires access to a secure signing module.
• PAR Execution: The agent's OAuth client must implement the full PAR flow, handling the back-channel push before initiating user-facing authorization.
• Token Binding Enforcement: When calling a FAPI resource server, the agent must correctly present the mTLS certificate or DPoP proof alongside the access token.
• Audit Logging: All steps—key usage, token requests, PAR calls—must be immutably logged for compliance with financial-grade audit trails. This ensures the autonomous agent's actions are as secure and verifiable as a human-driven integration.

The foundational authorization framework upon which FAPI is built. FAPI is a strict, opinionated security profile of OAuth 2.0, adding mandatory constraints where the base specification is permissive.

• Core Relationship: FAPI does not define new flows; it mandates how existing OAuth 2.0 flows (like Authorization Code with PKCE) must be secured.
• Key Differences: Where OAuth 2.0 allows bearer tokens, FAPI requires sender-constrained tokens (e.g., mTLS). Where OAuth 2.0 suggests PKCE for public clients, FAPI demands it.

The identity layer on top of OAuth 2.0. FAPI leverages and extends OIDC to provide high-assurance authentication for financial transactions.

• FAPI 1.0 Advanced: This profile is explicitly built on OpenID Connect, requiring the use of signed ID Tokens to convey identity claims.
• Hybrid Flow: FAI often mandates the OIDC Hybrid Flow, which returns both an authorization code and an ID token in the initial response, enhancing security and user experience.

The token format that is central to FAPI's security model. FAPI mandates the use of JWTs for access tokens and ID tokens to enable cryptographic validation.

• Signed Claims: All tokens must be signed as JSON Web Signatures (JWS), allowing resource servers to validate their integrity and origin without a network call.
• Strict Validation: FAPI specifies required JWT claims (e.g., iss, aud, exp, iat) and enforces tight tolerances for timestamps to prevent replay attacks.

A core sender-constraining mechanism mandated by FAPI to bind an access token to a specific client. It prevents stolen tokens from being used by unauthorized parties.

• How it Works: During the TLS handshake, the client presents its X.509 certificate to the server. The issued access token is cryptographically bound to this certificate.
• FAPI Requirement: For confidential clients (like backend servers), FAPI requires the use of mTLS or Demonstrating Proof-of-Possession (DPoP) to present access tokens, moving beyond simple bearer token usage.

An OAuth 2.0 security extension that is mandatory in FAPI for all public clients (e.g., mobile apps, SPAs). It mitigates authorization code interception attacks.

• Code Verifier & Challenge: The client creates a cryptographically random code_verifier and sends a derived code_challenge with the authorization request. It must later present the original code_verifier to exchange the code for a token.
• FAPI Enforcement: FAPI requires PKCE S256 (the SHA-256 hashing method), banning the plain transform method for stronger security.