OAuth Token Validator: Expiry and Standard Claims at a Glance
OAuth 2.0 access tokens are sometimes JWTs (self-contained, readable) and sometimes opaque reference strings (meaningless without calling the issuer) — knowing which kind you have changes what you can even check locally. This tool auto-detects the format, decodes JWT claims, checks expiry against the current time, and flags missing standard claims that would normally be expected.
iss, aud, sub, and scope are the standard OAuth-relevant JWT claims this tool checks for.
JWT vs. Opaque Access Tokens
The OAuth 2.0 spec doesn't mandate a specific token format — it's an implementation choice by the authorization server. JWT-format tokens let resource servers validate claims locally (with the right public key) without a network call. Opaque tokens push all validation to the authorization server via an introspection endpoint (RFC 7662), trading local readability for centralized revocation control.
What Claim Checking Can and Can't Tell You
Reading exp, iss, aud, and scope from a JWT's payload confirms the token's stated claims — but the payload is just base64-encoded JSON, trivially readable (and, without verification, trivially forgeable) by anyone. This tool checks the claims for completeness and expiry, but actual trust in a token requires verifying its cryptographic signature against the issuer's public key, which only your backend should do.
Why Missing Claims Matter
A production-quality OAuth access token should generally include exp (so it can't be used forever if leaked), aud (so a token issued for one API can't be replayed against another), and iss (so the resource server can confirm which authorization server it trusts issued it). Missing these isn't necessarily broken, but it's worth understanding why they're absent.
Practical Examples
Checking Token Expiry
The most common quick check.
- 1.Paste a JWT access token
- 2.exp claim: 1900000000
- 3.Result: valid until [decoded date/time]
Identifying an Opaque Token
No embedded structure to inspect.
- 1.Paste a random-looking token string (not 3 dot-separated segments)
- 2.Result: treated as opaque — validity requires calling the introspection endpoint
What Gets Checked
- Format detection: JWT vs. opaque
- exp: expiry status against current time
- nbf: not-yet-valid check
- iss / aud / sub: presence of standard claims
- scope: presence of permission scope
- alg: none: flags an unsigned token
Good Use Cases
- Quickly checking if an access token has expired
- Inspecting which scopes a token was issued with
- Debugging why a resource server rejects a seemingly-valid token
- Understanding the difference between JWT and opaque OAuth tokens
Frequently Asked Questions
Does this verify the token's cryptographic signature?
No — verifying a signature requires the issuer's public key (or shared secret), which this client-side tool doesn't have and shouldn't be trusted to hold. It decodes and inspects the claims and checks expiry, but true signature verification must happen on your backend or via the issuer's JWKS endpoint.
What's the difference between a JWT access token and an opaque token?
A JWT access token is self-contained and readable — its claims (expiry, scope, subject) can be decoded by anyone without contacting the server. An opaque token is just a random reference string with no embedded meaning; the resource server must call the authorization server's introspection endpoint to learn anything about it.
What do iss, aud, sub, and scope mean?
iss (issuer) identifies the authorization server that issued the token. aud (audience) identifies who the token is intended for. sub (subject) identifies the user or entity the token represents. scope lists the permissions the token grants — often space-separated strings like 'read:profile write:posts'.
Why does the tool warn when there's no exp claim?
OAuth access tokens are meant to be short-lived credentials — a token with no expiration is a significant security liability if it's ever leaked, since it would remain valid indefinitely with no way to force it to expire short of revoking it server-side.
Can I check if a token has been revoked?
No — revocation status is only known to the authorization server itself. A token can look completely valid by its claims (unexpired, well-formed) while having been explicitly revoked; only the issuing server's introspection or revocation-check endpoint can confirm current validity.
Is my token sent anywhere?
No, decoding happens entirely in your browser via base64url decoding and JSON parsing — nothing is transmitted, which matters since access tokens are sensitive credentials.