Notifications
Clear all
Topic starter
11/06/2026 11:14 pm
TL;DR: Native JWT support verifies bearer tokens against JWKS, exposes trusted claims to policy conditions, and centralises issuer, audience, and subject checks instead of duplicating parsing across services, according to Cerbos. That reduces boilerplate and audit drift, but it does not replace disciplined token governance or production verification controls.
NHIMG editorial — based on content published by Cerbos: native JWT support for policy-driven verification and claims usage
By the numbers:
- Credentials remain a leading initial action in breaches at 24 percent in 2024.
- The 2024 Verizon DBIR shows use of stolen credentials as the top initial action at 24 percent.
Questions worth separating out
Q: How should security teams centralise JWT verification across services?
A: Security teams should verify JWTs once at a policy decision point, then expose only validated claims to downstream logic.
Q: Why do JWT claims create risk when each service handles them differently?
A: JWT claims become risky when services parse, trust, or transform them in different ways.
Q: What should teams do when JWKS keys rotate frequently?
A: Teams should rely on JWKS endpoints, define a refresh interval or honour cache headers, and map requests to the correct keyset explicitly.
Practitioner guidance
- Centralise JWT verification at the policy layer Move signature, issuer, audience, and expiry checks out of application code and into one decision point so every service evaluates the same trusted claims.
- Define explicit JWKS rotation behaviour Set cache headers or a refresh interval, and document how each keyset is selected so key rotation works without restarts or ad hoc exceptions.
- Enforce claim consistency in policy conditions Require issuer, audience, and subject checks in CEL expressions before allowing a request to proceed, especially where multiple identity providers are in play.
What's in the full article
Cerbos' full article covers the implementation detail this post intentionally leaves for the source:
- Exact configuration examples for auxData.jwt, including cacheSize, remote keysets, and local fallback files
- Policy snippets showing how to combine request.auxData.jwt with principal and resource attributes in CEL
- Operational guidance for multiple issuers and key rotation without restarts
- Comparison points for native JWT handling versus app-side extraction and a bespoke PIP
👉 Read Cerbos' article on native JWT verification and policy claims →
Native JWT verification in Cerbos: what IAM teams need to know?
Explore further
12/06/2026 7:50 am
Centralised JWT verification is an identity governance control, not just an application convenience. When every service parses and validates tokens differently, policy drift becomes inevitable. A central verifier makes issuer, audience, and signature checks enforceable once and reused everywhere, which is exactly the kind of consistency identity governance depends on. Practitioners should treat token verification as part of access policy design, not as incidental plumbing.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
A question worth separating out:
Q: How do you know whether JWT verification is actually working as intended?
A: You know it is working when every service rejects the same invalid token for the same reason and valid tokens are accepted only after issuer, audience, expiry, and signature checks pass. If acceptance differs across services, the control is fragmented and the identity trust boundary is not stable.
👉 Read our full editorial: Cerbos native JWT verification reduces policy drift in identity checks
