2026-07-11 · 6 min read · Rahul Chitturi
- jwt
- auth
- debugging
A JWT that works for one user and fails with 401 for another is often a timing or claim mismatch, not a broken login screen. The token may be expired, not valid yet, issued for a different audience, or copied through a channel that trimmed a segment.
Start by decoding the token locally and reading the claims without treating them as trusted authorization data. You are inspecting the problem, not verifying the signature in the browser.
Check time claims before changing auth code
Clock skew shows up when servers, workers, and identity providers disagree by a few minutes. A token with nbf in the near future or exp just behind the request time can fail only in one region or deployment target.
- Convert exp, nbf, and iat to the same timezone as your logs
- Compare the identity provider time with API server time
- Confirm staging and production use the same issuer and audience
- Keep the original token copy beside any decoded payload snapshot
Compare claims across environments
Issuer and audience mismatches are easier to spot when you diff a known-good token against the failing token. Look for changed tenant IDs, scopes, algorithms, key IDs, or API resource names.
If the token was pasted through email, chat, or a test fixture, confirm no line wrapping, URL decoding, or quote escaping changed the compact form.
A Flashman workflow
Use the JWT decoder to inspect header and payload claims, the timestamp converter to read time fields, and the diff tool to compare tokens from two environments. Use Base64 only for isolated segments when you need to inspect encoding details.
Never paste production bearer tokens into shared tickets. Redact signatures and identifiers before asking for review, and verify authorization behavior server-side with the correct keys.