Only when those claims are tightly controlled and treated as part of the authorisation model. Embedding roles or feature flags can reduce lookups, but it also creates policy drift if the application does not re-check that the claim still matches current access rules.
Why JWT Claims Become an Authorisation Boundary
JWT claims are often treated as a convenient place to carry identity context, but roles and permissions are not just descriptive metadata once the application makes access decisions from them. If a token becomes the source of truth, then its claim design, issuance, lifetime, and validation rules are part of the authorisation model, not a cosmetic optimisation.
That distinction matters because a claim copied into a token can outlive the policy that created it. A user may be removed from a role, a feature flag may be disabled, or a delegated entitlement may be revoked, yet an already-issued token can still present the old state until expiry unless the application re-checks current policy or uses a short-lived, tightly governed token design.
When Claim-Based Access Is Reasonable, and When It Is Not
Embedding roles or permissions can be sensible when the decision is coarse-grained, the token lifetime is short, and the system has a clear rule for how quickly entitlement changes must take effect. In those cases, claims can reduce directory lookups and simplify distributed enforcement, especially in service-to-service flows where repeated introspection would add latency or coupling.
The approach becomes risky when claims are used as a permanent authorisation shortcut for privileges that change often or carry high impact. Fine-grained entitlements, dynamic context checks, admin rights, and exception-based access are poor candidates for long-lived JWT claims because the application can drift away from current policy and continue trusting stale authority.
For distributed systems, the safer pattern is to separate identity assertion from current permission state. Use the token to identify the subject and carry only the minimum stable assertions needed for enforcement, then depend on externalised authorisation, short token lifetimes, or a revalidation step where the decision must reflect current rules.
What Good Practice Looks Like in Production
A well-designed system treats JWT claims as one input into the decision, not the decision itself, unless the claim is intentionally authoritative and the full lifecycle is controlled. That means defining which claims are authoritative, which are advisory, how long they are valid, how revocation works, and what happens when the token and the policy disagree.
Operationally, teams should be able to answer four questions without ambiguity: who is allowed to mint the claim, what event invalidates it, how fast entitlement changes must propagate, and whether the application re-checks sensitive actions. If those answers are vague, the organisation is relying on stale authorisation even if the token format is technically correct.
Role and permission claims also need tight scope discipline. A claim that is acceptable for low-risk UI gating may be inappropriate for database write access, privileged administration, or customer data export. The higher the consequence of the action, the less suitable a cached claim is as the sole proof of current authority.
Risk and Threat Considerations
JWT claim overreach creates a predictable exposure: once a token carries more authority than the application can continuously validate, a stolen, replayed, or merely stale token can preserve access after the underlying entitlement should have been removed. This is especially problematic when organisations use self-contained tokens to avoid checking policy at request time.
Failure mechanism: The application accepts claim content as current authorisation state, but the claim is only a snapshot from issuance time. If role changes, revocations, or feature-flag updates are not re-evaluated, the token can continue to authorise actions that no longer match policy.
Impact: The result is policy drift, delayed revocation, and a larger blast radius for token theft or misuse. In a privileged path, that can mean continued administrative access, unauthorised feature use, or access to sensitive functions long after the business believes the permission was removed.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | JWT claims can directly drive function-level access decisions. |
| Recommendation — Revalidate privileged operations instead of trusting stale claim-based role checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWTs and claim-bearing tokens depend on credential and token lifecycle controls. |
| AC-6 — Least Privilege | Overstated roles in claims can expand access beyond current need. | |
| IA-9 — Service Identification and Authentication | Claim-bearing JWTs are often used by services and workloads to authenticate and authorize calls. | |
| Recommendation — Set short token lifetimes and revoke or rotate token material promptly. Limit claim scope to the minimum authority needed for the action. Authenticate service tokens separately and validate them before authorising requests. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | JWT claim design affects how access is granted and enforced. |
| Recommendation — Define when claims are authoritative and when current policy must override them. | ||
Practitioner Guidance
What to prioritise: Treat any role or permission claim as authoritative only if you can prove its revocation and expiry behaviour are acceptable for the action it protects. For high-impact operations, prefer a current authorisation check over trusting a long-lived token snapshot.
Decision rule: If the claim can unlock privileged, sensitive, or frequently changing access, keep the token minimal and re-check policy at request time or at least at the sensitive action boundary. If the claim only supports low-risk presentation logic, a controlled snapshot is easier to justify.
What to verify: Confirm token lifetime, revocation path, claim issuer, and whether downstream services independently validate the claim against current access rules. If any of those controls are absent, the claim is part of the attack surface, not just a convenience.
Practitioner takeaway: Put roles and permissions in JWT claims only when the application can tolerate policy staleness and has a deliberate revalidation strategy; otherwise, the token becomes a cached copy of authority rather than a trustworthy statement of current access.
Related resources from NHI Mgmt Group
- How do organisations decide whether to use a policy-based authorization model or keep permissions inside applications?
- When should organisations prioritise JWT group filtering over sending full group membership claims?
- How should organisations govern access reviews for RPA systems when workflows, roles, and permissions change frequently?
- Why does relying on roles inside a JWT create risk for application authorization?