INTRODUCTION

OAuth 2.0 provides the authorization framework, but it suffers from Request Tampering (modifying scope in the redirect URL) and Response Leakage (the auth code exposed in browser logs). The Financial‑grade API (FAPI) 1.0 Advanced profile, mandated by the UK OBIE and Brazil BCB, introduces three security invariants to solve these fundamental flaws:

1. PAR (Pushed Authorization Requests) : Moves the request payload from the fragile HTTP GET query string to a secure, mTLS‑protected POST, returning a short‑lived request_uri. This eliminates URL length limits (which are ~2,000‑8,000 characters depending on the browser) and prevents parameter tampering.

2. JARM (JWT‑Secured Authorization Response Mode) : Replaces the plaintext query parameters (?code=...) with a Signed and Encrypted JWT. This ensures that the response cannot be modified by an attacker (integrity) and that the code is hidden from browser logs (confidentiality) even if TLS is compromised.

3. mTLS + PS256: Mandates mutual TLS for client authentication (replacing static client secrets) and requires the RSA‑PSS (PS256) signing algorithm over the older PKCS#1 v1.5 (RS256) to provide probabilistic signatures, defending against the Bleichenbacher oracle attack.

This lesson focuses on the mathematical overhead of these additions. We will calculate the byte‑inflation of JARM signatures (and its negligible network impact), derive the Memory‑Cost Formula for PAR request storage in high‑throughput ASPSPs, and mathematically prove why PS256 provides strictly stronger cryptographic security than RS256 without a significant performance penalty.

LEARNING OBJECTIVES

1. Prove the PAR Necessity via URL Length Calculus—modeling the maximum possible length of an OAuth 2.0 request string (including authorization_details) and deriving the threshold at which it exceeds browser limits, forcing the use of a request_uri pointer.

2. Derive the JARM Overhead Function—calculating the exact byte‑size inflation of wrapping an authorization response in a JWT (JWS + optional JWE), and calculating its impact on network transit time (which is sub‑millisecond for modern fiber optics).

3. Analyze the PS256 vs. RS256 Security differential—formally comparing the probabilistic padding of RSA‑PSS against the deterministic padding of PKCS#1 v1.5, and proving that PS256 eliminates the signature forgery vector with a success probability of 1/(2^256).

4. Calculate the Total FAPI Latency Stack—summing the additional latency introduced by PAR (one extra round‑trip) and JARM (signature verification), proving that the total overhead (~63ms) is well within the 850ms UK p95 tolerance.

5. Formulate the Storage Complexity for PAR requests at scale—modeling the ASPSP’s Redis memory requirement using the formula Memory = (Avg_Request_Size) * (QPS) * (TTL), and designing a cleanup strategy using exponential time‑decay heuristics.

PART 1: PAR — Eliminating the Fragile GET Constraint

1.1 The URL Length Bypass

The standard OAuth 2.0 authorization request encodes the request object (scope, claims, redirect_uri, state, nonce) in a URL query string. The HTTP specification does not define a maximum length, but browsers like Internet Explorer impose a hard limit of 2,083 characters. With the authorization_details parameter (used for granular consent in the CDR and UK), the payload can easily exceed 4,000 characters.

PAR (RFC 9126) hijacks this. The TPP issues a POST request to the AS’s /par endpoint containing the same parameters in the body. The AS responds with a request_uri—a token of length ~100 characters (e.g., urn:ietf:params:oauth:request_uri:abc-123). The TPP redirects the PSU using this short URI, effectively reducing the URL length from potentially 4,000 bytes to ~100 bytes.

The Compression Ratio: Compression = 4000 / 100 = 40x.

1.2 The Storage Complexity (ASPSP Memory Model)

The ASPSP must store the PAR request payload until the PSU completes authentication (or until TTL expiry, typically 600 seconds). This creates a memory burden at scale.

Let:

• S = Average size of a stored PAR request (including metadata) = ~5 KB.

• QPS = Peak authorization requests per second = 10,000 requests/sec (high‑scale UK bank).

• TTL = Time to live for the PAR request = 600 seconds.

The total concurrent in‑memory storage requirement is calculated via Little’s Law:
Concurrent_Store = QPS * TTL = 10,000 * 600 = 6,000,000 requests.
Total_Memory = Concurrent_Store * S = 6,000,000 * 5 KB = 30,000,000 KB = 30 GB.

Impact: An ASPSP must provision ~30 GB of in‑memory Redis cache to handle peak PAR traffic. If the TTL is reduced to 300 seconds, memory drops to 15 GB, but increases the risk of the PSU timing out during SCA. We choose 600 seconds (the industry standard) as the equilibrium point where memory cost is acceptable (approx. $3,000/month in cloud Redis costs) to ensure a 99.95% success rate for user sessions.

PART 2: JARM — The Cryptographic Wrapper for Authorization Responses

2.1 Mathematical Integrity and Confidentiality

JARM mandates that the AS returns the authorization code inside a JWT. The TPP receives a single response parameter in the redirect URI.

Byte‑Size Overhead:

• The raw authorization response: ?code=abc...&state=xyz... (approx. 80 bytes).

• A JWT with a PS256 signature: Header (Base64, ~50 bytes) + Payload (Base64, ~150 bytes) + Signature (Base64 of 256‑byte signature, ~344 bytes). Total size: ~544 bytes.

Network Transit Math:
Assuming the redirect goes over a 1 Gbps fiber link:
Transit_Time = 544 bytes * 8 bits / 1,000,000,000 bps = 4.3 microseconds.
Even on a slower 100 Mbps network, transit time is only 43 microseconds. The overhead of JARM is dominated by CPU processing (signature verification), not network transfer.

The Verification CPU Cost:
Signature_Verification_Time = 0.5 ms (PS256).
This is entirely acceptable and adds only 0.5ms to the redirect time.

PART 3: PS256 vs. RS256 — A Formal Security Proof

Both are RSA‑based, but they differ in padding schemes.

• RS256 (PKCS#1 v1.5): Uses deterministic padding. This has been exploited historically via the Bleichenbacher attack (1998), where an attacker can decrypt or forge signatures by sending millions of malformed ciphertexts to an oracle that reveals whether the padding is valid. The attack complexity is approximately 2^40 (1 trillion) operations, which is borderline feasible for a nation‑state actor.

• PS256 (RSA‑PSS): Uses probabilistic padding. A random salt (minimum 32 bytes) is hashed with the message before signing. The signature includes the salt, making each signature computationally unique even for the same payload.

Mathematical Proof of Forgery Resilience:
In PKCS#1 v1.5, the signature s = m^d mod n lacks uniqueness in the low‑exponent space. In RSA‑PSS, the signature is s = (H(M || salt))^d mod n. Because the salt is randomly chosen, there is exactly 1 / (2^256) probability that two identical messages produce the same signature. Consequently, if an attacker intercepts a message and attempts to forge a signature for a slightly modified message, they face the discrete logarithm problem with exponent e, which is computationally infeasible.

Performance Penalty: PS256 is only ~2% slower than RS256 due to the extra SHA‑256 hash of the salt. For a 2048‑bit key, RS256 verifies in ~0.45ms, while PS256 verifies in ~0.46ms. The 0.01ms difference is negligible.

PART 4: THE TOTAL FAPI LATENCY STACK (Quantitative Summary)

Integrating FAPI into the OAuth 2.0 flow adds three distinct time components to the machine‑to‑machine handshake.

Conclusion: The FAPI security profile adds only ~13 milliseconds to the critical non‑interactive path. The standard OAuth 2.0 token exchange (without FAPI) takes ~100ms. FAPI turns this into 113ms. This is far below the 850ms UK p95 SLA, demonstrating that maximum security does not compromise performance.

CLOSING — THE FAPI VERTEX OF THE OPEN BANKING TRIFECTA

You have now mathematically proven why FAPI 1.0 Advanced is the ultimate security layer for Open Banking. PAR compresses the fragile GET request by a factor of 40x. JARM wraps the response in a 544‑byte cryptographic envelope, costing only 0.5ms to verify. PS256 eliminates the 1-in-2^40 Bleichenbacher attack vector in favor of the 1-in-2^256 RSA‑PSS forgeability.

Operational Risk: If you implement OAuth 2.0 without FAPI (using RS256 and no PAR), you are complying with only the letter of the OAuth standard but violating the spirit of UK FAPI regulations. The CMA will flag you for non‑compliance during the OBIE certification test, resulting in a failed integration.

Transition to Lesson 3.3: With the authentication and authorization secured, we must attach the legal payload—Consent. In Lesson 3.3, we will map the OAuth 2.0 scope to the granular consent permissions required by CDR (per‑account, per‑field), implement the PSD2 Article 67 right‑to‑revoke via the DELETE /consents endpoint, and mathematically analyze the 90‑day expiry re‑authorization cycle.