They can accept a token that was genuinely signed but still wrong for the service, expired, or issued by the wrong authority. That turns cryptographic validity into an authorization bypass opportunity. The practical failure is not broken signing, but incomplete verification logic at the application boundary.
What breaks when a service only checks the JWT signature?
A valid signature proves the token was minted by a trusted signer, but it does not prove the token is appropriate for the current service, audience, time window, or trust relationship. If the application stops at signature verification, it can treat a real token as a blanket pass, which turns a token validation gap into an authorization flaw at the boundary.
That failure is especially dangerous because it looks secure at first glance: the cryptography is intact, yet the service still accepts claims it should have rejected.
Which JWT claims must be verified, not just the signature?
The minimum set is the one that binds the token to the service and the request context. That usually includes the issuer, audience, expiry, not-before time, and any application-specific claims that drive access decisions. A service should also confirm the signing key is one it expects, not merely one that can produce a valid signature.
In practice, the mistake is to treat signature validation as the whole authentication story. It is only one control in a chain that also includes trust decisioning, claim evaluation, and authorization enforcement.
For a deeper look at token lifetime, revocation, and replay resistance, see NHIMG’s Token and Session Security Guide. When JWTs are used for workload-to-workload trust, the service identity model also matters, as described in Guide to SPIFFE and SPIRE.
Why does signature-only trust create an authorization bypass?
A signed JWT can be genuine and still malicious in context. If the token was issued for another audience, carried from another environment, or left valid after the intended time window, the service may accept an identity assertion that was never meant for it. That is how a verification shortcut becomes a privilege boundary failure.
This is also where forged or stolen signing material becomes catastrophic. If an attacker can mint tokens with a trusted signature, every downstream service that skips claim checks inherits the trust failure. NHIMG’s analysis of the Microsoft Storm-0558 key breach 2023 shows how token validity alone does not prevent abuse when the signing trust chain is broken.
Risk and Threat Considerations
Signature-only validation creates a predictable abuse path: an attacker, or even a legitimate caller holding a stale or mis-scoped token, can move across services that do not enforce audience, issuer, and expiry checks. The result is not cryptographic failure, but trust expansion beyond the token’s intended scope.
Failure mechanism: The service accepts any token with a valid signature and fails to reject tokens that are expired, mis-issued, or minted for a different audience.
Impact: Attackers can reuse real tokens for unauthorized access, bypass service boundaries, and turn one valid assertion into broader lateral movement or privilege gain.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | JWT signature-only trust is an authentication validation failure. |
| Recommendation — Verify issuer, audience, expiry, and signature before accepting any JWT. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWTs are bearer authenticators whose lifecycle and validation must be enforced. |
| IA-9 — Service Identification and Authentication | Service-to-service JWT use depends on authenticating the calling workload correctly. | |
| AC-3 — Access Enforcement | Claim checks are part of enforcing who may do what after authentication. | |
| Recommendation — Validate token lifetime, issuance, and revocation before granting access. Bind service tokens to the intended workload and reject tokens with the wrong trust context. Enforce claim-based authorization at the application boundary, not after signature check alone. | ||
| OWASP ASVS | V10 — OAuth and OIDC | JWT claim validation is central to token-based federated authentication flows. |
| Recommendation — Require correct issuer, audience, and token-use checks for every federated token. | ||
Practitioner Guidance
What to verify: Treat signature verification as the start of validation, not the end. Confirm issuer, audience, expiry, not-before, key selection, and the claim or scope that actually authorizes the action being requested.
Common mistake: Teams often validate the JWT library output and assume the token is safe. The safer rule is simple: if a token is cryptographically valid but not contextually bound to the service, it should be rejected.
Practitioner takeaway: A signed token is only trustworthy when its claims are checked against the service’s own trust boundary, otherwise the application is delegating authorization to whoever can obtain or replay a valid JWT.
Related resources from NHI Mgmt Group
- What happens when users trust cloud file-sharing links in email without checking the destination?
- What happens when organisations rely on third party services without checking how data can flow through them?
- What happens when a retailer expands into financial services without a strong trust foundation?
- What happens when digital verification services are expanded without a clear trust framework?