Handling JWTs in Java: validation, JWKS, and key rotation

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Secure JWT handling in Java depends on verifying signatures, constraining algorithms, validating claims, and using JWKS for key selection and rotation.

Why it matters: IAM teams need to treat JWT parsing as only the first step, because weak verification logic turns bearer tokens into an authorisation shortcut across APIs and services.

Context

JWTs are commonly used as bearer credentials in Java applications, but the security problem is not token parsing itself. The real governance gap is trusting claims before verification, especially when frameworks and libraries hide the underlying validation steps.

In Java, the verification model has to account for algorithm choice, claim checking, key discovery, and rotation. That makes JWT handling an identity control problem as much as an application concern, because the token becomes part of the authentication and authorisation boundary.

Key questions

Q: How should teams handle a JWT that parses successfully but has not been verified?

A: Treat it as untrusted input. A parsed token may expose claims, but it does not prove the issuer, signature, audience, or expiry are valid. Security teams should reject any design that uses payload values for authorisation before verification succeeds, because that turns a bearer credential into an unauthenticated assertion.

Q: Why do JWT verification failures often become authentication bypasses?

A: Because applications often trust claims too early or accept whatever algorithm the header advertises. When the verifier does not pin the expected signing method and validate issuer, audience, and expiration, an attacker can exploit the gap between decoding a token and proving it is legitimate.

Q: Where does JWT validation fail in Java applications that use JWKS?

A: It fails when key lookup, caching, or rotation handling is incomplete. If the verifier cannot refresh keys when a new kid appears, or if old keys disappear before issued tokens expire, legitimate authentication breaks and attackers may exploit fallback logic or inconsistent enforcement.

Q: What is the difference between JWT decoding and JWT verification?

A: Decoding only reads the token contents, while verification checks that the signature is valid and that the token matches the expected issuer, audience, and expiry rules. Decoding is useful for debugging. Verification is the step that makes the token trustworthy enough to use in authentication or authorisation decisions.

Technical breakdown

Signature verification and claim trust in Java JWTs

A JWT is only a signed assertion until the application verifies it. The signature proves integrity and issuer control, but the payload is readable by design, so claims such as iss, aud, sub, and exp must be checked before they are trusted. In Java libraries like Nimbus JOSE + JWT, parsing a token and verifying it are separate operations, which is where implementation mistakes happen. If an application uses claims from an unverified token, it has turned a bearer credential into an unauthenticated input. Practical implication: only allow authorisation decisions after full signature and claim validation succeeds.

Practical implication: require verified claims before any access decision is made.

JWKS, kid, and key rotation for distributed Java systems

JWKS solves a distribution problem, not a cryptography problem. Instead of hard-coding a single public key, the verifier fetches a set of public keys from a JWKS endpoint and uses the kid value in the JWT header to pick the right key. That matters when keys rotate, because old and new signing keys can coexist while tokens age out. A verifier that caches keys but cannot refresh on unknown kid values will eventually break production authentication. Practical implication: treat JWKS refresh and overlapping key availability as part of the authentication lifecycle, not an afterthought.

Practical implication: build for overlapping keys and automatic JWKS refresh during rotation.

Algorithm constraints and framework abstraction risks

JWT headers describe the signing algorithm, but the verifier must not accept that choice blindly. Algorithm confusion attacks exploit systems that treat the header as authoritative and fail to lock verification to the expected algorithm, such as RS256. Java frameworks can obscure this because Spring Security and library abstractions simplify the happy path while hiding the exact verification policy. The safer pattern is to make the verifier explicit about which algorithm, issuer, audience, and token source are acceptable. Practical implication: configure verification rules centrally, rather than relying on framework defaults or per-endpoint shortcuts.

Practical implication: pin accepted algorithms and centralise verification policy.

Threat narrative

Attacker objective: The attacker wants to present a token that the application will accept as a valid identity or permission grant without legitimate signing authority.

1. Entry occurs when an application accepts a JWT that can be parsed but has not yet been verified, or when it trusts the algorithm advertised in the header. That creates an opening for token manipulation, algorithm confusion, or abuse of stale key handling.
2. Credential abuse follows when the service uses claims from an unverified token, or when it selects the wrong signing key because JWKS lookup and kid handling are incomplete. The attacker benefits from bearer-token trust without proving authenticity.
3. Impact is unauthorised API access, privilege misuse, or forged identity assertions across services that treat the token as proof of authentication and authorisation.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JWT verification is an identity control, not a parsing step: Java teams often treat token decoding as if it were equivalent to trust establishment. It is not. The control point is the verification pipeline, where signature validation, algorithm pinning, and claim checks decide whether the token can govern access. The practitioner implication is straightforward: any design that consumes claims before verification has already failed.

JWKS makes key rotation a governance dependency: Distributed verification only works when old and new signing keys are managed as an intentional overlap period. That is not just cryptography hygiene, it is lifecycle governance for bearer trust. If the verifier cannot follow key rotation cleanly, authentication continuity and revocation discipline both degrade. Practitioners should treat key publication, cache refresh, and retirement windows as one control surface.

Algorithm confusion is a policy failure, not a library quirk: The real weakness appears when implementations allow the token header to choose the verification path. That assumption was designed for convenience, not for hostile input. In practice, the verifier must declare what it will accept before it processes any token, because dynamic acceptance expands the trust boundary beyond what the application intended.

Bearer-token trust debt accumulates when verification is fragmented: Java frameworks, multiple libraries, and per-service shortcuts make it easy for different endpoints to enforce different rules. That creates uneven authorisation behaviour inside the same application estate. The governance lesson is to standardise one verification pattern across services, because inconsistent JWT handling is itself an access-control defect.

Claim validation is the real authorisation boundary: Expiration, issuer, audience, and not-before checks determine whether the token applies in the current context. Without those checks, a validly signed token can still be wrong for the service that receives it. The practitioner implication is to validate context, not just cryptographic authenticity, before any request is allowed through.

What this signals

JWT trust debt grows when verification is split across libraries and services: Java teams often inherit a mix of framework defaults, custom filters, and library-specific behaviours. That creates a policy gap in which one service may validate correctly while another accepts weaker conditions. The programme-level answer is consistency, because identity assurance fails at the least controlled edge.

JWKS-backed verification should be treated as an operational dependency: Key discovery, cache refresh, and overlap during rotation all have to work together or token validation becomes brittle. Teams running distributed APIs should test rotation as a live operational event, not a theoretical cryptography exercise.

For practitioners

• Centralise JWT verification in one shared component Use a single verification path in your Spring Security filter or service interceptor so every protected endpoint applies the same signature, issuer, audience, and expiration checks.
• Pin accepted algorithms explicitly Configure the verifier to accept only the algorithm your issuer uses, such as RS256, and reject tokens that try to negotiate a different method through the header.
• Adopt JWKS for public-key lookup Fetch public keys from a JWKS endpoint and allow the verifier to refresh when it sees a new kid, rather than distributing PEM files by hand.
• Keep key rotation windows overlapping Publish new public keys before signing with them, keep retired keys available until all valid tokens expire, and avoid breaking services that still hold cached keys.
• Treat unverified claims as unsafe input Do not use payload values for access control, logging decisions, or user identity until the token signature, issuer, audience, and expiry have been checked successfully.

Key takeaways

• JWT handling in Java fails when teams confuse parsing with trust, because an unverified token can still expose claims that look authoritative.
• JWKS and kid-based lookup are essential in distributed systems because they let verifiers follow key rotation without manual PEM distribution.
• The durable control is a central verification pipeline that pins algorithms, checks claims, and refuses to use payload data until the token is proven valid.

Key terms

• Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
• JWKS: A JWKS, or JSON Web Key Set, is a machine-readable publishing format for public keys used by clients to verify signatures or encrypt tokens. It lets consumers fetch current key material automatically instead of relying on manual distribution, which is critical when keys rotate on a schedule.
• Kid: kid is the key identifier in a JWT header that tells a verifier which key from a JWKS should be used for validation. It matters most when issuers rotate keys, because the application must select the right public key without trusting the token’s payload first.
• Algorithm pinning: Algorithm pinning means the verifier only accepts a preapproved signing algorithm instead of trusting whatever the token header declares. This prevents algorithm confusion and downgrade-style mistakes. For JWTs in Java, pinning is part of authentication policy, not a cosmetic configuration choice.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.