INTRODUCTION

In Module 2, we established the physical boundaries of the API—the URIs, the schemas, and the pagination cursors. However, those endpoints are fundamentally stateless and agnostic regarding the caller. To operationalize PSD2’s SCA mandate (Article 97) and the CMA’s security requirements, we must implement a formal delegation protocol.

OAuth 2.0 (RFC 6749) is not merely a library; it is a mathematical framework for secure delegated access. It decouples the client (TPP) from the resource owner (PSU) credentials, using a bearer token as a proof of authorization. However, OAuth 2.0 alone suffers from a fundamental vulnerability in the authorization code exchange—the code interception attack. This is mitigated by PKCE (RFC 7636), which introduces a cryptographic binding between the initial request and the token exchange, based on the SHA‑256 hash of a high‑entropy secret.

This lesson deconstructs OAuth 2.0 and OIDC through a security‑first lens. We analyze the entropy requirements for PKCE (why 43–128 characters is not optional), the clock‑skew tolerance in JWT expiration (derived from the nbf and exp formulas), and the refresh‑token rotation entropy (which reduces the theft window to a single request). We will formally prove why the Authorization Code Flow is the only acceptable grant type for Open Banking, using threat modeling and probability theory.

LEARNING OBJECTIVES

  1. Formalize the OAuth 2.0 delegation model using set theory—defining the relationships between the Resource Owner (PSU), Client (TPP), Authorization Server (AS), and Resource Server (RS), and mapping their interactions to cryptographic proofs.

  2. Derive the PKCE Collision Probability: calculate the exact probability of an attacker guessing the code_verifier (minimum 43‑byte entropy, ~344 bits), proving that brute‑force is computationally infeasible under current bitcoin hash‑rate assumptions.

  3. Analyze the Token Expiry Calculus—formulating the optimal exp / iat window (900 seconds) based on the balance between session longevity and the risk of bearer token theft, factoring in Bayesian probability of token exposure over time.

  4. Quantify the End‑to‑End Latency Budget for the Authorization Handshake—deconstructing the latency into user‑interactive (SCA, ~3‑5s) and machine‑to‑machine (redirect + token exchange, ~300ms), and deriving the Critical Path Formula for the non‑interactive back‑channel.

  5. Construct the Refresh Token Rotation Model—designing the deterministic algorithm for refresh token issuance, including the mathematical derivation of the one‑time‑use property that neutralizes replay attacks.

PART 1: THE FORMAL DELEGATION MODEL — Actors, Scopes, and Threat Vectors

1.1 The OAuth 2.0 Actors and Their Trust Relationships

OAuth 2.0 defines four distinct roles. In Open Banking, these roles map strictly to regulated entities:

  • Resource Owner (RO) : The PSU. A human actor with asymmetric cryptographic keys (biometrics/passwords). Trust boundary: The RO trusts the Authorization Server (AS) not to misuse their credentials.

  • Client (C) : The TPP. A software application (AISP/PISP) acting on behalf of the RO. Trust boundary: The Client is untrusted by default; it must prove its identity via client assertions (mTLS/JWT).

  • Authorization Server (AS) : The bank’s authentication and token issuance endpoint. Trust boundary: The AS holds the authoritative session state.

  • Resource Server (RS) : The bank’s data API (/accounts, /payments). Trust boundary: The RS trusts the AS exclusively; it must validate the access token’s signature and scope.

The Delegation Theorem: The AS issues a time‑limited, scope‑bound access token (T) to the Client. The RS accepts T as proof that the RO authorized C to access specific resources R. Mathematically, Authorization = {RO, C, Scope, TTL} forms a quadrupole constraint.

1.2 The Threat Taxonomy (Why the Implicit Flow is Deprecated)

OAuth 2.0 defines several grants. The Authorization Code Flow is the only secure grant for Open Banking because it uses a back‑channel (client‑to‑AS) to exchange the code for tokens, hiding tokens from the browser history. The Implicit Flow returns the token directly in the redirect URI fragment—attack vector: browser history, referrer headers, and malicious JavaScript on the redirect URI can exfiltrate the token.

Probability of token leakage (Implicit Flow) : Assuming an attacker controls a single malicious script on the redirect page, the probability of capturing the token is 1.0. The Authorization Code Flow reduces this to the probability of intercepting a one‑time code and the PKCE verifier—which is astronomically low (see Part 2).

PART 2: THE PKCE MATHEMATICS — Entropy, SHA‑256 Collision, and Time‑based Security

2.1 The Cryptographic Binding (Code Verifier vs. Code Challenge)

PKCE introduces a dynamic client secret. The Client generates a code_verifier, a high‑entropy string. The Client sends the code_challenge (the SHA‑256 hash of the verifier) during the authorization request. During the token exchange, the Client sends the plain code_verifier. The AS computes SHA256(verifier) and compares it to the stored challenge.

The Entropy Requirement: RFC 7636 mandates the verifier must be between 43 and 128 characters (minimum entropy of 43 bytes * 8 bits/byte = 344 bits).

  • Probability of Collision (Brute‑Force) : An attacker has N attempts before the code expires (typically 60 seconds). Let the verifier space size be 2^344. The probability of a successful guess within 1 million attempts (10^6) is:
    P(guess) = 10^6 / 2^344 ≈ 10^6 / 10^103.5 ≈ 10^-97.5
    This is effectively zero. For context, the total number of atoms in the observable universe is ~10^80. The PKCE verifier space is 10^23 times larger than the atom count.

2.2 The Time‑Drift Calculus (JWT iat, nbf, and exp constraints)

JWTs rely on absolute time. FAPI 1.0 mandates strict constraints to prevent Replay attacks.

  • Constraint 1: exp - iat ≤ 900 seconds (15 minutes). This limits the window of abuse if a token is stolen.

  • Constraint 2: nbf (Not Before) must be ≤ 90 seconds before iat.

The Clock‑Skew Math: The AS and Client clocks may differ by up to δ ms. To ensure a legitimate client isn’t rejected, the AS allows a grace period. However, a larger grace period increases the attack window.
Let T_actual be the actual time, T_AS be the AS time, and T_Client be the client time. The tolerance margin is defined as ε = max(|T_AS - T_Client|). In globally synchronized NTP networks, ε is typically ≤ 1 second. Therefore, FAPI’s 90‑second nbf window is extremely generous (3 orders of magnitude larger than drift), intentionally over‑provisioned to account for extreme network latency, but mathematically proving that replay attacks are only feasible within this 90‑second window.

Formula for valid authentication window: T_AS_current must satisfy:
iat - 90 ≤ T_AS_current ≤ exp

PART 3: TOKEN LIFECYCLE — Refresh Tokens and the Bayesian Theft Model

3.1 Refresh Token Rotation (The One‑Time‑Use Concept)

Access tokens are short‑lived (900 seconds). To avoid re‑authenticating the PSU, the AS issues a refresh_token. Static refresh tokens are a liability—if stolen, the attacker has long‑term access. Refresh Token Rotation mandates that each token exchange (grant_type=refresh_token) issues a new refresh token and invalidates the old one.

The Bayesian Risk Reduction:
Let P(Theft) be the probability that a refresh token is stolen over its lifetime L. If L = 24 hours and P(Theft) per hour is λ, then P = 1 - e^(-λL).
With rotation, if a token is stolen at time t, the attacker has exactly one exchange opportunity (the window between t and the next legitimate refresh). If the legitimate Client refreshes before the attacker, the stolen token is invalid. If the attacker refreshes first, the legitimate Client gets a “stale token” error, triggering a fraud alert. Rotation reduces the expected theft utility to zero, as there is no long‑term asset.

3.2 Access Token (JWT) Structure and Validation Math

While Open Banking uses opaque tokens in some cases, FAPI mandates structured JWTs for traceability. The Access Token contains the scope and consent_id.

The Resource Server validates the token by verifying the digital signature (using the AS’s public key from the JWKS). The cost of verification is mathematical:

  • Algorithm: PS256 (RSA‑PSS). Verification involves modular exponentiation: s^e mod n.

  • The complexity is O(k^2) where k is the bit length (2048 bits). For a 2048‑bit key, verification takes approximately 0.5 to 1.0 milliseconds on a modern CPU core (Intel Xeon Skylake). This is negligible compared to the 100ms database query latency.

PART 4: THE LATENCY BUDGET EQUATION

The Authorization Handshake is a multi‑hop process. To meet the UK 850ms p95 SLA for the non‑interactive portions, we decompose the time into a quantifiable formula.

Formula: T_total = T_redirect_RTT + T_PAR_Push + T_token_Exchange

  • T_redirect_RTT: The browser redirect from TPP to AS. Typically ~100ms (assuming CDN edge).

  • T_PAR_Push: The TPP pushes the auth request to /par. This is an mTLS connection. Latency = TCP_Handshake(3ms) + TLS_1.3_1‑RTT(4ms) + HTTP_RoundTrip(30ms) = 37ms.

  • T_token_Exchange: The TPP exchanges the code for tokens. This is an mTLS connection to /token. Latency = TLS_Resumption(2ms) + JWT_Validation(1ms) + DB_Read(5ms) + Token_Gen(2ms) = 10ms.

Total Non‑Interactive Machine Time = ~147ms.
The User‑Interactive time (SCA fingerprint/OTP) dominates at ~3‑5 seconds. However, because this involves the PSU, the 850ms SLA is suspended for the login page (it only applies to the API calls after the token is issued). Once the token is issued, API calls see the ~100ms overhead.

Transition to Lesson 3.2: With OAuth 2.0 and OIDC established as the foundational algebra, we must now apply the financial‑grade transformations. Lesson 3.2 introduces the FAPI 1.0 Advanced constraints—enforcing strict URI length reductions via PAR, adding JARM to prevent response tampering, and mandating PS256 over RS256 to eliminate probabilistic signature forgery vectors.

 
PreviousNext