Use OAuth for delegated access and JWT for compact, verifiable claims, then enforce actual permission decisions in a separate authorization layer. Tokens should carry identity and scope context, not become the source of truth for business rules. This avoids brittle code, reduces rework when policies change, and keeps access decisions consistent across applications and resources.
Use the token as proof, not policy
OAuth and JWT work best when each keeps a narrow job. OAuth is the delegation layer: it expresses who is allowed to ask for access and under what scopes. JWT is the token format: it can carry claims that are compact, signed, and easy to validate. The mistake is to let downstream services treat the token as the full authorization model for business decisions.
That separation matters because access control should reflect the resource owner’s policy, not whatever happened to be encoded at issuance time. A JWT can help a service authenticate the caller and understand context, but it should not become the place where teams bury customer tiers, workflow approvals, product entitlements, or exception logic.
When teams want a practical reference point for the identity side of token handling, NHIMG’s Ultimate Guide to NHIs is useful because it covers OAuth, tokens, governance, and rotation in the wider control model.
Where JWTs belong in the access flow
A good pattern is to treat the JWT as input to a decision, not the decision itself. The token can prove the caller was issued a valid credential, identify the subject, and carry bounded claims such as audience, issuer, expiry, and approved scopes. The service then uses those claims as one signal, while the actual permission check happens in a separate authorization layer or policy service.
This approach keeps responsibilities clean. Authentication answers, “Who are you and is this token valid?” Authorization answers, “May this subject perform this action on this resource right now?” If those are merged, every application ends up reimplementing policy logic, which makes policy drift almost inevitable.
Teams that need implementation guidance on claims, scopes, and API-facing controls can cross-check against OWASP API Security Top 10 and OWASP ASVS, both of which reinforce the need for explicit authorization checks rather than blind trust in client-presented data.
How to keep authorization separate without breaking developer velocity
The cleanest operating model is usually: validate token integrity, extract only the claims you actually need, and call a centralized policy decision point or authorization service for the final answer. That can be an internal service, an external policy engine, or a resource-server-side rules layer, but it should be separate from the token itself. If the policy changes, the application should not need a token schema redesign.
This is also where teams should be careful with overloading JWT claims. If every feature flag, role assignment, or entitlement gets packed into long-lived tokens, revocation becomes slow and stale tokens become dangerous. Short-lived tokens, narrow scopes, audience restriction, and server-side policy evaluation are the safer default because they reduce the blast radius of a token that is stolen, replayed, or simply outdated.
For teams building on standardized workload and service identity patterns, SPIFFE workload identity specification is a useful parallel reference for keeping identity assertions bounded while leaving authorization to policy.
Risk and Threat Considerations
When JWTs are treated as authorization engines, the main risk is policy ossification. A token that was valid at issuance can outlive the business context it was meant to represent, which creates stale access, inconsistent enforcement across services, and a larger payoff if the token is stolen or replayed.
Failure mechanism: Teams encode roles, entitlements, or resource rules into claims and then trust those claims as if they were current policy, so authorization decisions stop reflecting the real state of the user, workload, or resource.
Impact: Compromised or stale tokens can preserve access longer than intended, policy changes become expensive to roll out, and different services may reach different answers for the same request.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | API and Tool Authorization | JWT claims must not replace explicit authorization for service actions. |
| Recommendation — Enforce explicit authorization checks before any token-backed action. | ||
Practitioner Guidance
What to verify: Check whether every service validates token signature, issuer, audience, and expiry, then performs a fresh authorization decision for the requested action. If a service can grant access from claims alone, it is already too coupled to the token.
Common mistake: Teams often start with “just add one more claim” and end up using JWTs as a distributed database for access rules. That shortcut feels efficient early on, but it makes revocation, auditability, and cross-application consistency much harder later.
Practitioner takeaway: Keep JWTs small, verifiable, and context-bearing, then make authorization an explicit policy decision that can change without forcing every token and every consumer to change with it.
Related resources from NHI Mgmt Group
- How should teams use JWTs in an authorization architecture without turning them into the policy engine?
- How should teams use a foreign data wrapper to apply authorization checks in PostgreSQL without embedding policy logic in application code?
- How should security teams implement JWT authentication without turning tokens into a permanent session mechanism?
- How should teams implement JWT-based authentication and authorization without mixing the two concerns in application code?
