Should You Verify JWT Signatures? A Decision Guide

A 16-year-old researcher recently accessed approximately 17.3 trillion database rows in Microsoft's internal analytics service. The vulnerability wasn't a sophisticated exploit. The service simply didn't verify the cryptographic signature on JSON Web Tokens (JWTs).

Your authentication layer likely processes JWTs. This guide helps you determine whether your current JWT validation approach protects against identity spoofing or exposes your system.

The Decision You're Facing

You're implementing or auditing an authentication system using JWTs. You must decide: do you verify only the claims inside the token, or do you also verify the cryptographic signature that proves who issued it?

This isn't a theoretical choice. The Microsoft incident shows what happens when you validate claims without proving the token's origin. An attacker who controls the claims without proving issuance can bypass every downstream access control you've built.

Key Factors That Affect Your Choice

Token Source
Where do your JWTs originate? If they come from your own identity provider and never cross trust boundaries, you control the signing keys. If they arrive from external identity providers, federated systems, or third-party APIs, you're trusting another entity's signing process.

Attack Surface
Is your API publicly reachable, or does it sit behind a VPN? The Microsoft service was internal, yet still vulnerable. VPN access and network segmentation don't eliminate the need for cryptographic verification; they just reduce the pool of potential attackers.

Downstream Trust
What happens after authentication? If your system makes authorization decisions, queries databases, or accesses restricted resources based on claims in the JWT, unsigned tokens let attackers impersonate any identity they choose.

Compliance Requirements
GDPR Article 32 requires Technical and Organisational Measures appropriate to the risk, including measures to ensure confidentiality and integrity. If your system processes personal data, failing to verify JWT signatures likely violates this requirement.

Path A: Full Cryptographic Verification (Default Choice)

Choose this when:

• Your system processes personal or restricted data
• JWTs arrive from any external source
• Your API is reachable from outside your direct control
• Authorization decisions depend on claims in the token
• You're building a new authentication layer

Implementation requirements:

1. Retrieve the public key from your identity provider's JWKS endpoint
2. Verify the signature using the appropriate algorithm (RS256, ES256)
3. Reject any token with an invalid or missing signature before reading claims
4. Validate claims only after signature verification succeeds
5. Implement key rotation: cache public keys but refresh them periodically

Why this path:
Signature verification proves the token came from your identity provider and hasn't been tampered with. Without it, an attacker can craft a token claiming to be anyone, including administrators, and your system will trust it. The Microsoft incident showed exactly this: the service validated tenant, audience, and application claims, but because it didn't verify the signature, those checks provided no protection.

This is fail-closed authentication. If verification fails, access stops.

Path B: Claims-Only Validation (High-Risk Exception)

Choose this when:

• You're working with legacy systems that can't be modified
• You're implementing a temporary workaround during migration
• The system doesn't process personal or restricted data
• You've documented the risk and accepted it formally

Mandatory compensating controls:

1. Network isolation: restrict API access to a single, monitored network segment
2. Break-glass access logging: record every authentication attempt with full token contents
3. Anomaly detection: alert on unusual claim patterns or tenant mismatches
4. Time-bound exception: set a concrete deadline for implementing full verification
5. Prior consultation: if you process high-risk personal data, consult your supervisory authority

Why this path rarely works:
You're trusting that network controls will stop attackers from reaching your API. The Microsoft case proves this assumption fails. Even internal analytics services need cryptographic verification because internal access doesn't equal trusted access.

If you choose this path, treat it as technical debt with a defined remediation timeline, not a permanent architecture.

Path C: Hybrid Verification (Temporary Migration State)

Choose this when:

• You're migrating from claims-only to full verification
• You need to validate both old (unsigned) and new (signed) tokens during transition
• You're running parallel authentication systems

Implementation requirements:

1. Check for signature presence first
2. If signature exists, verify it cryptographically; reject if invalid
3. If no signature exists, log a deprecation warning and validate claims only
4. Set a cutoff date: after this date, reject all unsigned tokens
5. Monitor the ratio of signed to unsigned tokens weekly

Transition timeline:

• Week 1-2: Deploy hybrid verification in monitoring mode
• Week 3-4: Begin rejecting invalid signatures while accepting unsigned tokens
• Week 5-8: Notify clients about upcoming unsigned token deprecation
• Week 9: Reject all unsigned tokens

This path should last weeks, not months. The longer you accept unsigned tokens, the longer you're vulnerable.

Summary Matrix

What the Microsoft Incident Reveals

The researcher used AI for repetitive enumeration and authentication testing, but the breakthrough came from questioning an assumption: how does the application interpret the user identity field? AI accelerated discovery; human reasoning found the flaw.

Your security testing should follow the same pattern. Use automation to test authentication endpoints at scale, but task humans with questioning your fundamental assumptions about trust.

There is currently no evidence that malicious actors exploited the Microsoft vulnerability. That's not a reason to delay verification, it's a reminder that you discover incidents only when someone looks.

Verify JWT signatures. Reject unsigned tokens. Fail closed. The alternative is broadcasting administrator access to anyone who can craft a JSON object.