INTRODUCTION

With the Access Token issued and consent granted, the TPP begins to call the Resource Server (/accounts, /payments). The Resource Server is presented with a Bearer token. It must answer a critical question: Is this token valid right now?

There are two ways to answer this:

1. Local Validation (Stateless): The Resource Server independently verifies the JWT’s signature, checks the exp claim, and extracts the scope and consent_id. This is fast (~0.5ms) but cannot enforce runtime revocation—if the consent is revoked after the token was issued, the token remains cryptographically valid until it expires (which could be 15 minutes later).

2. Token Introspection (Stateful): The Resource Server calls the Authorization Server’s introspection endpoint (RFC 7662) with the token. The AS checks its database for the consent_id status and returns active: true/false. This is secure (immediate revocation) but adds network latency (~5‑10ms).

FAPI 1.0 Advanced allows both, but strongly recommends the “hybrid” model: Local Validation for primary performance (checking the JWT signature) combined with cached Introspection for consent revocation status.

This lesson formalizes the Introspection Algebra, proves why a TTL‑managed cache (max‑age: 5s) provides a near‑real‑time revocation check without the overhead of a per‑request database call, and models the Revocation API (RFC 7009) that allows TPPs to proactively terminate tokens. We will also analyze the mathematical upper bound of a 15‑minute token validity and its relation to the market risk of fraud.

---

LEARNING OBJECTIVES

1. Differentiate Validation Methods Statistically—comparing the Latency Distribution of Local Validation (Mean: 0.5ms, Std Dev: 0.1ms) vs. Introspection (Mean: 7ms, Std Dev: 2ms), and deriving the optimal cache hit ratio (≥ 95%) to keep the p95 latency under 2ms.

2. Design the Introspection Cache—defining the Cache Entry Model { "active": bool, "expiry": timestamp, "scope": [...] } and calculating the optimal TTL (T_cache = 5s) using the Freshness‑Accuracy Trade‑off Formula to respect the CDR’s 2‑hour revocation SLA.

3. Formalize the Token Revocation Calculus (RFC 7009)—modeling the POST /revoke endpoint, deriving the one‑way hash that binds the refresh token to the access token, and proving that revocation renders all dependent tokens inert instantly.

4. Quantify the Sliding Refresh Token Model—deriving the mathematical formula for refresh_token expiry (Expiry = max(24h, Last_Refresh_Time + 8h)), and calculating the probability that a user’s session remains active for 30 days without re‑authenticating.

---

PART 1: LOCAL JWT VALIDATION VS. INTROSPECTION — The Performance/Consistency Trade‑off

1.1 The Stateless Approach (JWT Validation)

The Resource Server receives a JWT. It downloads the ASPSP’s JWKS once (cached for 12 hours) and verifies the signature.

Latency Breakdown:

• Cache Lookup (public key): 0ms (hot cache).

• Base64 Decode: 0.1ms.

• RSA‑PSS Verification: 0.4ms.

• Expiry Check (exp > now): 0.05ms.

• Total: 0.55ms (p95).

The Limitation: If a PSU revokes consent at T=1s, and the token expires at T=900s, the token remains cryptographically “valid” for 899 seconds. The TPP can still call the Resource Server. To the RS, the signature is valid, so it accepts the request—violating the PSU’s right to immediate revocation.

1.2 The Stateful Approach (Introspection)

The Resource Server sends a POST /introspect request to the AS.

Latency Breakdown:

• Network RTT (AS‑RS): 2ms (intra‑datacenter).

• DB Lookup (Redis): 1ms.

• Serialization: 0.5ms.

• Total: 3.5ms.

While 3.5ms is acceptable, doing this for every API call (e.g., 10,000 RPS) introduces high load on the AS. To achieve 10,000 RPS, the AS would need to handle 10,000 DB queries/sec, which is feasible but expensive.

The Hybrid Solution (RFC 7662 with caching):
The RS introspects the token once, obtains { "active": true, "ttl": 900, "scope": [...] }, and caches it locally for a short duration. The Cache TTL must be much smaller than the Token TTL to enforce revocation.

---

PART 2: THE REVOCATION AND CACHE INVALIDATION ALGEBRA

2.1 The Revocation Propagation Window

CDR mandates ≤2 hours. By setting the introspection cache TTL to 5 seconds, the worst‑case propagation delay is: Network_Propagation (Gossip) + Cache_TTL + Processing_Time.
= 50ms + 5,000ms + 100ms = 5.15 seconds.

This is significantly under the 2‑hour SLA, providing a safety margin of 99.9% compliance.

Mathematical Proof of Cache Freshness:
Let U be the time until the cache entry is stale. If the cache TTL is Δ, the RS operates with a freshness metric F = 1 - e^(-λΔ), where λ is the revocation rate. Since Δ is 5 seconds and λ is extremely low (revocations are rare), the probability of serving a stale entry is negligible.

2.2 The Revocation Endpoint (RFC 7009)

OAuth 2.0 defines a standard revocation endpoint. The TPP can call this endpoint with its refresh_token to kill the entire session.

Token Revocation Logic:
When the AS receives a revocation request:

1. Invalidate the refresh_token in the database.

2. Emit a revoke event to the introspection cache bus (e.g., Redis Pub/Sub).

3. All RS nodes receive the invalidation event, instantly clearing the cache entry.

This process ensures that the cache is invalidated before the 5‑second TTL expires, effectively making revocation instantaneous in practice.

---

PART 3: THE REFRESH TOKEN SLIDING SESSION MODEL

3.1 Absolute vs. Sliding Expiry

• Absolute Expiry: Token expires exactly 24 hours after issuance (mathematically rigid).

• Sliding Expiry: Token expires X seconds after the last refresh request.

The Formula for Sliding Expiry:
Let T_issue be the time of initial authentication. The refresh token is valid for a maximum of 24 hours or until 8 hours after the last refresh.
Expiry = min(T_issue + 86400, Last_Refresh + 28800).

The Benefit:
If a user actively uses the app, they refresh their tokens automatically (e.g., every 14 hours). The session never expires. If they stop using the app, the token expires after 24 hours. This model maximizes security (reducing the static window) while maximizing usability.

3.2 The Refresh Probability

The probability that a session survives for D days without re‑authentication is low if the user is active. However, because the sliding window continuously resets, the session can theoretically last forever. This allows TPPs to maintain a seamless UX without forcing the PSU to re‑authenticate for 30 days, provided the consent itself remains active (which auto‑expires at 90 days). The intersection of Consent Expiry and Refresh Token Expiry creates a hard ceiling at 90 days.

---

PART 4: THE PERFORMANCE BUDGET FOR TOKEN MANAGEMENT

The p95 latency for an API call includes the Token Validation Time. By using the Hybrid Introspection model, the worst‑case latency is controlled.

Conclusion: The hybrid model keeps the average token validation latency under 1ms, which is crucial for meeting the 850ms UK SLA. The introspection miss (when the cache is cold) occurs only for new tokens (once per token) and adds 6ms, which is still negligible.

---

CLOSING — THE RUNTIME SECURITY LOOP

You have now closed the loop on Authorization. The PSU grants consent (Lesson 3.5), the TPP receives a cryptographically secure token bound to their client certificate (Lesson 3.4), and the Resource Server validates that token in near real‑time using a hybrid introspection cache (Lesson 3.6).

If the PSU revokes consent, the REVOKE event propagates through the cache bus within 5 seconds, ensuring the ASPSP complies with the CDR’s 2‑hour SLA with an extremely generous safety margin.

Transition to Lesson 3.7: With authorization fully secured, we now move to the SCA Exemptions and Risk Analysis. Not every transaction requires SCA—PSD2 allows exemptions for low‑value (≤€30) and trusted beneficiaries. In Lesson 3.7, we will mathematically model the Risk‑Based Authentication (RBA) logic, calculating the Fraud Rate (FR) and the False Positive Rate (FPR) to dynamically decide when to downgrade the SCA requirement, ensuring the TPP’s conversion funnel is maximized.