Directly issuing JWTs to public clients can expose personal data inside the token and create brittle dependencies on token contents. If applications start relying on embedded claims, any change in those claims can break workflows or authorization logic. Opaque tokens reduce that exposure because the sensitive data stays behind the introspection boundary.
Why JWTs Create More Operational Coupling for Public Clients
JWTs are self-contained, so the client and any downstream service can read claims without a lookup. That convenience is also the problem for public clients, because token content starts to act like an application contract. Once teams depend on those claims for decisions, token shape, claim names, and claim semantics become operational dependencies that are hard to change safely.
For public clients, the operational issue is not only exposure but also fragility. A token that carries user, device, tenant, or entitlement data expands the number of places where sensitive information can surface, including logs, caches, analytics, and debugging paths. If that token is copied into workflows, the result is tighter coupling between authentication format and business logic.
Opaque tokens avoid much of that coupling by keeping the sensitive state behind the authorization server or introspection boundary. The client still presents a token, but the application no longer needs to treat embedded claims as a stable source of truth for business decisions. That separation makes claim changes, revocation, and data minimisation easier to manage.
Why Claim Reuse Becomes a Maintenance and Security Problem
The biggest long-term risk comes when teams begin to trust JWT claims for more than identity assertions. A claim that was originally informational can become a dependency for authorisation, routing, feature flags, tenant selection, or audit logic. At that point, any schema change, issuer change, or audience change can break more than one path at once.
This is especially troublesome in mobile apps, browser-based apps, and other public clients where the token is not tightly protected. Because the client environment is user-controlled, tokens can be inspected, copied, replayed within their validity window, or handled by third-party components. The more meaning you embed in the token, the more places there are for that meaning to be observed or misused.
operational risk rises further when teams assume JWT contents are authoritative forever. If downstream services perform local validation but also hard-code claim expectations, teams lose flexibility to rotate issuers, narrow scopes, or remove data fields without coordinated releases. That creates brittle rollout paths and increases the chance of production incidents during normal identity changes.
Why Opaque Tokens Are a Safer Boundary for Public Clients
Opaque tokens shift the trust boundary back to the authorization server. Instead of distributing sensitive claims everywhere, applications ask a central service what the token means at the time of use. That design reduces exposure, improves revocation behaviour, and makes it easier to change claim structure without breaking every consumer.
This does not make opaque tokens automatically better in every case. They introduce a dependency on token introspection or equivalent lookup infrastructure, so availability and latency must be planned for. The trade-off is usually acceptable when the alternative is distributing sensitive or business-critical state across untrusted client environments and multiple backend services.
For teams that need self-contained tokens, the safer pattern is to keep JWTs narrow, short-lived, and focused on what the resource server must verify locally. Anything beyond that should be treated as a design decision with lifecycle consequences, not as free metadata.
Risk and Threat Considerations
Public-client JWTs create two classes of exposure: disclosure of claims that should not leave the trust boundary, and operational fragility when business logic starts depending on those claims. The same design that reduces round-trips can also increase blast radius if the token is copied, logged, cached, or interpreted inconsistently across services.
Failure mechanism: Sensitive or semantically important claims are embedded in a bearer token that can be observed outside the issuing boundary, while applications become dependent on those claims for logic that should have remained server-controlled.
Impact: Token content changes can break workflows, revocation becomes harder to reason about, and a compromise of token handling surfaces more data and more authorization context than necessary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWTs and opaque tokens both need disciplined lifecycle and revocation handling. |
| AC-6 — Least Privilege | Minimizing JWT claims limits exposure and downstream overuse of token data. | |
| Recommendation — Manage token lifetime, rotation, and revocation with IA-5 discipline. Limit token contents to the minimum claims needed for access decisions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token handling errors in public clients can weaken authentication trust and validation. |
| Recommendation — Validate token audience, issuer, and expiry before trusting any JWT claims. | ||
Practitioner Guidance
What to verify: Check whether any downstream service treats JWT claims as a source of business truth rather than as a narrow authentication assertion. If a claim change would require multiple code changes, you already have a brittle dependency.
Decision rule: If the token needs to carry sensitive attributes or fast-changing state, prefer an opaque token or a server-side lookup model. If a JWT is unavoidable, keep the claim set minimal and define which claims are stable enough to be consumed by more than one service.
Practitioner takeaway: The operational goal is not to eliminate JWTs, but to prevent client-side token contents from becoming an uncontrolled contract that leaks data and locks your architecture into hard-to-change assumptions.
Related resources from NHI Mgmt Group
- Why do public MCP servers increase risk in developer environments using local AI tools?
- Why does the EU AI Act increase the operational burden for companies using high-risk AI?
- Why does using a vendor-specific OpenTelemetry distribution increase operational lock-in risk?
- Why does weak AI literacy increase compliance and operational risk for organisations using AI?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
