Chapter 16: Zero Trust Identity — When Every Request Is an Authentication Decision

This is Part 16 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we walked through FAPI. Chapter 16 is the architectural paradigm sitting underneath all of it: Zero Trust.

16.1 — Identity as the Perimeter

The traditional network perimeter assumed employees sat at desks inside a corporate network, using corporate devices. A firewall at the edge decided who got in; once you were in, you were trusted. Every assumption in that model is now wrong: remote work, BYOD, cloud services, partner integrations, mobile devices.

Zero Trust replaces the network perimeter with identity as the perimeter. There is no "inside." Every request is authenticated and authorized on its own merits, regardless of where it came from. For OpenID Connect systems, that means treating authentication not as a one-time event but as a continuous posture.

16.2 — Continuous Verification and CAEP

Classical OIDC validates a token at the time of the API call and trusts it for the rest of its lifetime. That works when nothing changes. In real life, users get fired, devices get infected, accounts get compromised — and the system should respond in seconds, not wait for the next token expiry.

The Continuous Access Evaluation Protocol (CAEP) is the emerging OpenID Foundation/IETF spec that makes this real. When a significant event happens — termination, credential change, detected compromise — the IdP pushes a signed event to every registered resource server. Receivers invalidate tokens, terminate sessions, and require re-authentication immediately.

CAEP is not everywhere yet, but it's where the industry is heading. Major IdPs are implementing it; conformant clients are emerging. Chapter 16 walks through the event model, the HTTP webhook and pull-based variants, and the operational requirements on the receiving side.

16.3 — Device Trust and Conditional Access

A valid token on a compromised device is still a compromise. Device trust bridges this gap: the system evaluates the posture of the device making the request — OS patched, disk encrypted, endpoint protection running, MDM enrollment status — and feeds that into the authorization decision.

Conditional access is the policy engine that reads device posture, identity context, and request sensitivity, and decides: grant, step up, deny. A user from a managed laptop gets through; the same user from an unmanaged tablet gets challenged or blocked for sensitive operations. OIDC carries this context via acr (authentication context) and custom claims that downstream APIs can inspect.

What Chapter 16 Sets Up

After Chapter 16 you should see identity as the foundation of a broader Zero Trust architecture rather than just the login layer. CAEP is the mechanism that ties identity state to real-time access decisions; device trust is how you stop trusting the endpoint by default. Both are patterns that will be standard within a few years; implementing them early is a competitive advantage.

Next up — Chapter 17: Federation Between Organizations. We open Part VI with the multi-org side of identity: B2B trust chains, partner federation, and how to let partners' users access your systems safely without giving their IdP direct access to your application's guts.