Chapter 14: Hardening Your Identity Stack — Setting the Defaults That Keep You Safe

This is Part 14 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we enumerated the threats. Chapter 14 sets the defaults that neutralize most of them without having to remember.

14.1 — Redirect URI Rules (Exact Match, Every Time)

The golden rule of redirect URIs is exact string matching — no wildcards, no substring matches, no "close enough." Register the precise URLs your application uses, and reject anything that doesn't match byte for byte. This single policy closes open-redirect abuse, mix-up attacks, and half the creative ways attackers try to steal authorization codes.

The corollary is: plan for the variants. Register http://localhost:3000/callback for dev, register https://staging.app.example.com/callback for staging, register https://app.example.com/callback for prod. Use a short allowlist of specific URIs rather than one that pretends to cover everything.

14.2 — Audience Validation: Solving the Confused Deputy Problem

The aud claim tells you which application a token was issued for. If you don't check it, you'll accept tokens that were issued for other applications in the same identity provider — which is exactly how the confused deputy problem becomes a compromise.

Pass a single expected audience value (your client_id) into your token validator; reject anything else. In microservices architectures with multiple clients behind the same IdP, every service must validate its own audience. Getting this wrong is how a token for a dashboard ends up authorizing a payments API.

14.3 — Token Lifetimes: The UX-Security Knob

Access tokens should be short — 5 to 15 minutes is the range for most applications, shorter for high-stakes ones. The window an attacker has with a stolen token is exactly this duration. Refresh tokens can live for days or weeks, but they should have an absolute expiration (often 90 days) regardless of refresh count, so a single compromised refresh token can't provide indefinite access.

Users never see these numbers unless you get them wrong. Get them right and the security-vs-friction tradeoff disappears into the background.

14.4 — Refresh Token Hygiene

Three principles govern refresh tokens:

• Binding — a refresh token can only be redeemed by the client it was issued to. Combined with DPoP or mTLS, the token is bound to cryptographic material the attacker doesn't have.
• Rotation — every refresh returns a new refresh token and invalidates the old one. Reuse of an old token signals theft.
• Revocation — at the IdP (on credential change, account recovery, user-triggered logout) and at the application (session logout, forced reauth). User-facing "active sessions" UI helps users self-revoke.

These disciplines turn refresh tokens from "the credential that defeats you if stolen" into "the credential that can be compromised safely."

What Chapter 14 Sets Up

After Chapter 14 you should have a one-page hardening checklist you can run against any OIDC deployment: exact redirect matching, strict aud validation, short access-token lifetimes, rotating refresh tokens with absolute expiry, and real revocation. None of these are exotic — but it's striking how often production systems ship with one or more of them missing.

Next up — Chapter 15: Financial-grade API (FAPI) and High-Stakes Security. For financial services, healthcare, and critical infrastructure, the hardening defaults aren't enough. FAPI specifies the profile: PAR, JAR, mandatory DPoP or mTLS, request signing, response encryption. Chapter 15 is for the contexts where a breach ends in a regulator's office.