FAPI: Financial-Grade API Security for Edge Architectures

Financial services APIs handle the most sensitive data on the internet — bank account balances, transaction histories, payment instructions, and identity verification records. When these APIs are delivered through content delivery networks for latency reduction and geographic availability, every security control must operate at the same level of rigor as a direct connection to the bank's infrastructure. The Financial-Grade API (FAPI) security profiles, developed by the OpenID Foundation, define exactly how OAuth 2.0 and OpenID Connect must be configured for this level of security. FAPI 2.0 mandates sender-constrained tokens, Pushed Authorization Requests, and JWT-secured authorization responses — mechanisms that prevent the token theft, authorization tampering, and replay attacks that standard OAuth configurations leave open.

This article examines how FAPI security requirements intersect with CDN edge architectures, covering the implementation of sender-constrained tokens at edge nodes that terminate TLS, PAR enforcement at the edge function layer, JARM validation for authorization responses, and the regulatory compliance requirements that govern financial API delivery across jurisdictions. We provide concrete configurations for edge nodes that must maintain FAPI compliance while delivering the performance benefits of edge computing.

What Is FAPI and How Does It Differ from Standard OAuth 2.0?

Standard OAuth 2.0, as defined in RFC 6749, was designed as a flexible authorization framework suitable for a wide range of applications. This flexibility comes at a security cost: the base OAuth 2.0 specification permits bearer tokens (which can be replayed by anyone who intercepts them), authorization requests with parameters in the URL (which can be tampered with), and authorization responses with codes in query parameters (which can be leaked through browser history). These weaknesses are acceptable for low-risk applications like social media integrations but are categorically unacceptable for financial services.

FAPI 2.0 Security Profile eliminates these weaknesses through four mandatory requirements. First, all access tokens must be sender-constrained — cryptographically bound to the client's identity through either mTLS certificate binding (RFC 8705) or DPoP proof-of-possession (RFC 9449). A stolen sender-constrained token is useless without the corresponding private key. Second, authorization requests must use Pushed Authorization Requests (PAR, RFC 9126), which transmit request parameters through an authenticated back-channel rather than the browser's URL. Third, authorization responses should use JARM (JWT-Secured Authorization Response Mode), wrapping the authorization code in a signed JWT. Fourth, PKCE with S256 is mandatory for all authorization code flows, preventing authorization code interception attacks.

For API acceleration through CDN edge nodes, FAPI compliance means the edge must understand and enforce each of these mechanisms. The edge is not a passive proxy — it actively validates sender-constrained tokens, enforces PAR, and verifies JARM signatures as part of the security infrastructure.

How Do Sender-Constrained Tokens Work at CDN Edge Nodes?

Sender-constrained access tokens are the cornerstone of FAPI security. Unlike bearer tokens that can be used by anyone who possesses them, sender-constrained tokens are cryptographically bound to the client's identity — typically through the client's TLS certificate. The access token's JWT payload contains a cnf (confirmation) claim with an x5t#S256 value that is the SHA-256 thumbprint of the client certificate used during the token request. Any resource server receiving this token must verify that the presenting client's certificate thumbprint matches the cnf claim.

CDN edge nodes that terminate TLS connections face a fundamental challenge with sender-constrained tokens. When the client connects to the edge node via mTLS and presents both the access token and client certificate, the edge node verifies the binding. But when the edge node forwards the request to the origin (the financial API server), it establishes a new TLS connection where the original client certificate is not present. The origin API server cannot verify the sender constraint because it does not see the client's certificate.

The solution is a two-hop mTLS architecture where the edge node performs the sender-constraint verification and communicates the verified identity to the origin through a trusted header. The edge node extracts the client certificate's SHA-256 thumbprint, compares it against the cnf.x5t#S256 claim in the JWT, and if they match, adds a X-Client-Cert-Thumbprint header containing the verified thumbprint. The origin trusts this header only because the edge-to-origin connection itself uses mutual TLS, ensuring that only authenticated edge nodes can set this header.

# Edge nginx configuration for FAPI sender-constrained token verification
map $ssl_client_s_dn $fapi_client_id {
    default "";
    ~CN=(?<cn>[^,]+) $cn;
}

server {
    listen 443 ssl http2;
    server_name api.bank.example.com;

    # Edge TLS configuration
    ssl_certificate     /etc/nginx/ssl/edge.crt;
    ssl_certificate_key /etc/nginx/ssl/edge.key;
    ssl_protocols TLSv1.3;

    # Client mTLS (FAPI requirement)
    ssl_client_certificate /etc/nginx/ssl/openbanking-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 3;

    location /api/v1/ {
        # Extract client cert thumbprint for sender-constraint
        set $cert_thumbprint $ssl_client_fingerprint;

        # Forward to origin with verified identity
        proxy_pass https://origin-api.internal;
        proxy_ssl_certificate /etc/nginx/ssl/edge-origin.crt;
        proxy_ssl_certificate_key /etc/nginx/ssl/edge-origin.key;

        # Pass verified FAPI identity headers
        proxy_set_header X-Client-Cert-Thumbprint $cert_thumbprint;
        proxy_set_header X-Client-ID $fapi_client_id;
        proxy_set_header X-Auth-Method "fapi-mtls";

        # FAPI-required security headers
        proxy_set_header X-Forwarded-Client-Cert $ssl_client_cert;

        # Prevent caching of financial API responses
        proxy_cache off;
        add_header Cache-Control "no-store";
        add_header Pragma "no-cache";
    }
}

How Does the Edge Enforce Pushed Authorization Requests?

Pushed Authorization Requests (PAR) address a vulnerability in the standard OAuth authorization flow: the authorization request parameters (client_id, redirect_uri, scope, state, code_challenge) are transmitted in the browser's URL, where they can be logged by proxies, visible in browser history, and tampered with by malicious browser extensions or compromised DNS. PAR moves these parameters to an authenticated back-channel request from the client to the authorization server.

The PAR flow works as follows: the client sends an authenticated POST request to the authorization server's PAR endpoint containing all authorization parameters. The authorization server validates the parameters, stores them, and returns a request_uri reference. The client then redirects the user to the authorization endpoint with only the client_id and request_uri in the URL — no sensitive parameters are exposed.

The CDN edge enforces PAR by rejecting authorization requests that contain raw parameters instead of a request_uri. The edge function inspects requests to the authorization endpoint and blocks any request that includes redirect_uri, scope, response_type, or code_challenge as query parameters. Only requests with a valid request_uri (matching the authorization server's expected format and not expired) are forwarded.

This enforcement happens at the API gateway layer of the edge, where request inspection and routing decisions are made before any upstream communication. The WAF rules can be configured to flag and block non-PAR authorization requests as policy violations, providing an additional enforcement layer.

How Does JARM Protect Authorization Responses at the Edge?

JWT-Secured Authorization Response Mode (JARM) protects the authorization response — the redirect from the authorization server back to the client that carries the authorization code. In standard OAuth, the authorization code is a plain value in the redirect URL's query string, making it vulnerable to interception through browser history, referrer headers, and network logging. JARM wraps the entire authorization response in a signed JWT, ensuring integrity and authenticity.

The edge can validate JARM responses by checking the JWT signature against the authorization server's JWKS. When the authorization server redirects to the client through the CDN edge, the edge function intercepts the redirect, extracts the response parameter containing the JARM JWT, verifies the signature, checks the iss, aud, and exp claims, and forwards the validated response to the client application. If validation fails, the edge blocks the redirect and logs a potential authorization response tampering event.

JARM validation at the edge provides defense-in-depth: even if an attacker manages to intercept and modify the authorization response between the authorization server and the CDN edge (through DNS hijacking or BGP route manipulation), the signature verification will fail, and the modified response will be rejected. This is particularly important for financial services where the authorization code can be exchanged for access tokens that grant account access.

What Are the Edge Caching Restrictions for Financial APIs?

Financial API responses must never be cached at CDN edge nodes. Account balances, transaction lists, payment statuses, and identity verification results are user-specific, time-sensitive, and confidential. Standard CDN caching strategies that serve cached responses to multiple users are categorically incompatible with financial API security requirements.

The edge configuration for financial APIs must include Cache-Control: no-store on all responses, Pragma: no-cache for backward compatibility with HTTP/1.0 proxies, disabling of the edge's cache hierarchy for financial API paths, and stripping of any caching-related headers (ETag, Last-Modified) from responses to prevent conditional caching. The edge must also ensure that financial API response bodies are not logged, stored in memory beyond the request lifecycle, or written to disk at any point during proxy processing.

Despite the caching prohibition, CDN edge delivery still provides significant performance benefits for financial APIs. Latency optimization through geographically distributed edge nodes reduces round-trip time to the origin. TLS 1.3 session resumption at the edge reduces handshake overhead for returning clients. HTTP/2 and HTTP/3 multiplexing over the edge-to-origin connection reduces head-of-line blocking. And the edge's DDoS protection ensures that financial APIs remain available under attack without requiring the financial institution to maintain its own DDoS mitigation infrastructure.

How Do You Implement FAPI-Compliant Rate Limiting at the Edge?

Financial APIs require rate limiting that balances security against availability. Overly aggressive rate limiting can prevent legitimate financial transactions from completing, while insufficient rate limiting allows credential stuffing, account enumeration, and brute-force attacks. FAPI-compliant rate limiting at the edge must consider both the technical rate limiting architecture and the regulatory requirements for API availability.

Open Banking regulations typically mandate minimum availability and response time SLAs for financial APIs. PSD2 requires that Account Information Service Providers (AISPs) can access account data through APIs with the same availability and performance as the bank's own customer-facing channels. The CDN edge's rate limiting must enforce per-client quotas (preventing any single Third-Party Provider from monopolizing API capacity), per-endpoint limits (higher limits for read-only account information endpoints, lower limits for payment initiation endpoints), and per-user consent tracking (a TPP can only access accounts for which the user has granted consent).

The edge enforces these limits using the client identity extracted from the mTLS certificate's organizational unit, which maps to the registered TPP identity in the Open Banking directory. The JWT claims in the access token provide additional context: the consent ID identifies the specific user authorization, the scope restricts which API endpoints can be accessed, and the expiration prevents stale consent from being used.

What Are the Audit and Compliance Requirements for Financial APIs at the Edge?

Financial regulators require comprehensive audit trails for all API access. The CDN edge must generate audit records that include the timestamp (millisecond precision, UTC), the client identity (from mTLS certificate), the authorization context (consent ID, scopes, token claims), the API endpoint and method, the response status code, the response time, and the edge node location. These audit records must be stored in tamper-evident logs with cryptographic integrity verification, retained for the period required by the applicable regulation (typically 5-7 years for financial records), and available for regulatory examination on request.

The edge audit log pipeline must route logs to compliant storage within the appropriate jurisdiction. EU financial API logs must be stored within the EEA. UK Open Banking API logs must be accessible to the Financial Conduct Authority. Australian CDR API logs must be available to the Australian Competition and Consumer Commission. The monitoring infrastructure must support real-time alerting on anomalous API access patterns that could indicate fraud, unauthorized access, or consent violations.

For organizations operating financial APIs across multiple regions through a global CDN, the compliance framework must ensure consistent FAPI enforcement at every edge location. The CDN architecture should use a centralized policy management system that distributes FAPI configuration to all edge nodes, with automated compliance testing that verifies FAPI conformance at each edge location. Non-compliant edge nodes must be automatically removed from the load balancing rotation until compliance is restored.

How Do You Test FAPI Compliance at CDN Edge Nodes?

FAPI compliance testing at the edge requires running the OpenID Foundation's FAPI Conformance Suite against the CDN edge endpoint rather than the origin API directly. The conformance suite tests sender-constraint verification (presenting a token with a mismatched certificate thumbprint must be rejected), PAR enforcement (authorization requests with raw parameters must be rejected), JARM validation (authorization responses with invalid or missing JWT signatures must be rejected), PKCE enforcement (authorization code exchange without a valid code verifier must be rejected), and client authentication (requests without valid mTLS client certificates must be rejected).

The test suite should be run against the edge endpoint in each geographic region to verify consistent FAPI enforcement across all edge server locations. Automated conformance testing should be integrated into the CDN configuration deployment pipeline, blocking any configuration change that causes FAPI conformance failures. This continuous testing approach ensures that security configuration updates, nginx optimizations, or edge function deployments do not inadvertently weaken FAPI compliance.

The token authentication infrastructure at the edge must be regularly audited to ensure that the JWKS cache contains current signing keys from the authorization server, certificate revocation checking (OCSP or CRL) is functioning correctly, clock synchronization across edge nodes is within the tolerance required for token expiration checks (typically 5 seconds), and the sender-constraint verification logic correctly extracts and compares certificate thumbprints across all supported TLS library versions.

FAPI-compliant edge delivery transforms CDN infrastructure from a performance optimization layer into a security enforcement platform for financial services. By implementing sender-constrained tokens, PAR, JARM, and rigorous rate limiting at the network edge, organizations can deliver financial APIs with both the low latency that users expect and the security guarantees that regulators require. The edge becomes the compliance boundary where every financial API request is authenticated, authorized, integrity-verified, and audited before it reaches the bank's core systems.