Advanced Token Inspection & Claims

The Anatomy of Claims

The payload of a JWT is essentially a JSON object containing "claims". A claim is simply a piece of information asserted about a subject. While the beauty of JWTs is that you can inject any custom JSON data you want into the payload (like a user's display name or their current subscription tier), the IETF has standardized a set of "Registered Claims" to ensure interoperability between different systems.

The Big Seven Registered Claims

When inspecting a token for security or debugging purposes, you should always pay close attention to these seven specific fields:

• iss (Issuer): Identifies the principal (the server or service) that created and issued the JWT. This is crucial in multi-tenant architectures where multiple identity providers might issue tokens.
• sub (Subject): Identifies the principal that is the subject of the JWT. This is almost always the unique database ID of the user who logged in.
• aud (Audience): Identifies the intended recipients of the JWT. If an API receives a token, but its own identifier is not listed in the aud claim, the API must reject the token. This prevents a token issued for a "billing" service from being maliciously used against an "admin" service.
• exp (Expiration Time): A Unix timestamp identifying the exact moment the token becomes invalid. Security best practices dictate that this lifespan should be as short as possible (typically 15 to 60 minutes) to minimize the window of opportunity if a token is stolen.
• nbf (Not Before): A Unix timestamp identifying the time before which the JWT MUST NOT be accepted for processing. This is useful for issuing tokens that only become active in the future.
• iat (Issued At): A Unix timestamp identifying the exact moment the JWT was created. This can be used to determine the age of the token.
• jti (JWT ID): A unique, cryptographic identifier for the specific token. This is often used by high-security systems to prevent "replay attacks" by tracking which specific tokens have already been consumed.

The Importance of Temporal Validation

One of the most frequent mistakes developers make is verifying the cryptographic signature of the token, but forgetting to manually validate the temporal claims (exp and nbf). A token might have a perfectly mathematically valid signature, but if the exp timestamp was yesterday, it is a dead token. Always ensure your JWT verification library is configured to strictly enforce expiration constraints.