They assume a token can hold enough detail to drive every authorization decision. That breaks down with ABAC, ReBAC, and large resource sets because the token grows too large, becomes hard to manage, and still cannot express centralized policy cleanly. Fine-grained authorization needs policy logic outside the token, not more claims inside it.
Why This Matters for Security Teams
JWTs are attractive because they are portable, self-contained, and easy to validate at scale. The problem starts when teams try to turn them into a live policy engine. As soon as authorisation depends on resource relationships, environment state, or rapidly changing entitlements, the token becomes a snapshot that ages poorly. Fine-grained access control needs current policy decisions, not just more embedded claims.
That matters because access decisions are only as accurate as the data they are based on. If the token is oversized, stale, or too context-heavy, teams end up weakening token lifecycle discipline, increasing revocation pain, and spreading policy logic across applications. In practice, many security teams discover the limitation only after a permission change, tenant move, or relationship update has already created the wrong access outcome.
For teams dealing with broader application access patterns, the more durable pattern is to keep JWTs focused on authentication and coarse-grained session context, then evaluate fine-grained rules in a central policy layer. For baseline application control expectations, OWASP ASVS is a useful reference point for separating authentication from access control design.
How It Works in Practice
A JWT works well when the relying service needs a compact set of assertions, such as who the subject is, which issuer signed the token, and perhaps a small number of coarse claims. It breaks down when teams ask it to carry per-resource entitlements, relationship graphs, attribute combinations, or policy decisions that need to reflect changing data. At that point, the token is no longer just a session artifact, it is being asked to replace a policy decision point.
The practical failure is usually one of scale and staleness. The more claims you add, the larger the token becomes, the harder it is to transmit, cache, inspect, and revoke consistently. The more often you refresh it, the more operational burden you create. The more rarely you refresh it, the more stale the decision becomes. Fine-grained authorisation should instead evaluate the token as an input, then consult policy and authoritative attributes at decision time.
- Use JWTs for subject identity, issuer trust, audience, and short-lived session context.
- Keep fine-grained rules in a policy service or application-side enforcement layer.
- Fetch live attributes, relationships, or entitlements when the decision depends on current state.
- Use short token lifetimes and revocation-friendly patterns when claims might become stale quickly.
If a token must encode many per-object permissions to function, the design is already signalling that authorisation belongs elsewhere. These controls tend to break down in multi-tenant systems with large resource sets because token size, policy churn, and revocation latency grow faster than the token model can safely absorb.
Common Variations and Edge Cases
Tighter token design often improves clarity but reduces convenience, so teams have to balance self-containment against operational freshness. There is no universal standard that says exactly how many claims is too many, but current guidance suggests treating token bloat as a design smell once authorisation starts depending on frequently changing business state.
One common edge case is read-heavy systems that want to cache permissions for performance. That can work if the cached decision is explicitly bounded, short-lived, and backed by a predictable refresh path. It becomes risky when teams treat cached claims as authoritative for long periods, especially where ownership changes, role changes, or relationship changes must take effect quickly.
Another edge case is centralised policy with distributed enforcement. That is usually the right direction, but it requires clean ownership of policy data, clear cache invalidation, and a reliable source of truth for entitlements. When those pieces are weak, teams often overcompensate by stuffing more into the JWT, which makes the original problem worse rather than better.
Teams also get tripped up by mixing authentication and authorisation concerns. A token can prove that a subject authenticated, but that does not mean it should decide every access outcome. The safe default is to let the JWT carry identity context and let policy logic decide whether access is allowed for the specific resource and action.
Risk and Threat Considerations
The main risk is over-trusting a bearer token as if it were a full authorisation system. That creates exposure when claims drift away from live entitlements, when permissions change after issuance, or when a token is reused in a context it was never meant to cover.
Failure mechanism: Teams encode too much policy into claims, then rely on the token long after the underlying attributes, relationships, or access rules have changed. Attackers benefit when stale tokens continue to authorise actions that the current policy would deny, or when token contents leak internal structure that should have remained in a policy service.
Impact: Excessive access, delayed revocation, poor auditability, and inconsistent enforcement across services. At scale, this can turn one bad design choice into systemic authorisation drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic Access Control | JWT overuse often reflects confused access decision design. |
| Recommendation — Separate authentication claims from runtime authorisation decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | JWTs are bearer credentials whose scope and lifetime must stay bounded. |
| Recommendation — Limit token scope and lifetime to reduce bearer credential exposure. | ||
| NIST CSF 2.0 | PR.AC-4 — Access permissions are managed, incorporating the principles of least privilege and separation of duties | Fine-grained access control depends on least-privilege enforcement beyond token contents. |
| Recommendation — Enforce least privilege in the authorisation layer, not inside the token. | ||
| CIS Controls v8 | 6 — Access Control Management | JWT misuse often creates weak access review and revocation handling. |
| Recommendation — Review and revoke access centrally instead of embedding every permission in JWT claims. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | JWTs may carry session context, but authentication assurance must remain distinct from authorisation. |
| Recommendation — Bind tokens to appropriate assurance and keep authorisation separate from login proof. | ||
Practitioner Guidance
What to prioritise: Keep JWTs small and stable, and move any decision that depends on live resource state, relationships, or rapidly changing entitlements into a policy layer. If the permission model is becoming harder to express in a token, that is usually the signal to stop adding claims rather than to expand the token further.
What to verify: Confirm that every claim used for access control has a clear owner, refresh rule, and expiry expectation. Verify that the system still behaves correctly when the token is stale, when a role changes mid-session, and when a user or service loses access immediately.
Practitioner takeaway: JWTs are excellent for asserting identity and session context, but fine-grained access control fails when teams confuse a signed assertion with an always-current policy decision.
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to use Zanzibar-style authorization for every access control decision?
- What do teams get wrong about fine-grained access control?
- What do teams get wrong when they try to scale authorization from simple roles to fine-grained policy models?
- What do teams get wrong when they add custom roles and fine-grained permissions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
