Chapter 15: FAPI and High-Stakes Security — When the Defaults Aren't Enough

This is Part 15 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we set hardening defaults. Chapter 15 is for the contexts where those defaults are insufficient: financial services, healthcare, critical infrastructure.

15.1 — What FAPI Is and Why It Matters

Financial-grade API (FAPI) is a set of OpenID Foundation specifications that pins OIDC and OAuth 2.0 down to profiles suitable for high-value scenarios. Open Banking (PSD2 in Europe, equivalents elsewhere) made it mandatory; any system that moves money, exposes medical data, or touches critical infrastructure benefits from its discipline.

FAPI comes in two profiles currently in use: FAPI 1.0 Advanced (request signing, mTLS or DPoP, response encryption, strict token handling) and FAPI 2.0 (builds on FAPI 1.0 with simpler requirements and an updated threat model, increasingly the target for new deployments).

15.2 — Pushed Authorization Requests (PAR)

Traditional OAuth authorization requests put everything — client_id, scope, redirect_uri, state, nonce — into a URL that passes through the user's browser. Browser history, referrer headers, and proxy logs can all see them. That's fine for most apps and a problem for high-stakes ones.

PAR (RFC 9126) moves the authorization request to a back-channel POST. The client sends parameters directly to the IdP over HTTPS, and the IdP returns a short-lived request_uri that the browser then carries. Parameters never appear in a URL; the request is cryptographically bound to the client; replay windows are measured in minutes.

15.3 — JWT-Secured Authorization Requests (JAR)

JAR (RFC 9101) takes a different route to the same destination: bundle authorization parameters into a signed JWT and send it as a single request parameter. The IdP verifies the signature using the client's registered public key, which gives you integrity, authenticity, and (with encryption) confidentiality in one.

PAR and JAR can be combined — PAR carries a JAR request object to the back-channel — which is the preferred pattern in FAPI 2.0. Chapter 15 walks through the interaction and the implementation burden on both sides.

15.4 — Transitioning from FAPI 1.0 Advanced to FAPI 2.0

If you're currently on FAPI 1.0 Advanced, the move to 2.0 is meaningful but not radical: relaxed TLS certificate pinning (in favor of certificate transparency), optional response encryption, clarified DPoP requirements, and an updated threat model. Chapter 15 walks through the migration checklist, compatibility considerations, and the realistic timelines different jurisdictions are settling on.

What Chapter 15 Sets Up

After Chapter 15 you should be able to recognize when FAPI-profile security is warranted (any system where a single successful attack is an existential event), understand the specific mechanisms FAPI adds on top of base OIDC, and plan either a greenfield FAPI 2.0 deployment or a 1.0-to-2.0 migration with clear eyes about the scope.

Next up — Chapter 16: Zero Trust Identity. We close Part V with the architectural paradigm that reframes all of this: identity as the perimeter, continuous verification via CAEP, device trust and conditional access. Zero Trust is where the identity stack stops being "how users log in" and becomes the foundation of how the organization decides to grant any access at all.