JWT jti (JWT ID) Claim
Learn about the JWT jti (JWT ID) claim, how it uniquely identifies tokens, its role in preventing replay attacks, and implementation patterns for tracking.
Detailed Explanation
The jti (JWT ID) claim provides a unique identifier for a specific JWT. Its primary purpose is to prevent the same token from being used more than once, which is known as replay attack prevention. The jti value must be assigned in a manner that ensures there is a negligible probability of the same value being accidentally assigned to a different token.
Format and generation:
{
"sub": "user123",
"jti": "550e8400-e29b-41d4-a716-446655440000",
"iat": 1700000000,
"exp": 1700003600
}
The specification does not mandate a specific format for jti, but UUIDs (v4 or v7) are the most common choice. Some implementations use cryptographically random strings, auto-incrementing database IDs, or composite values combining a timestamp and random component. The key requirement is uniqueness within the issuer's domain.
Replay attack prevention:
To prevent replay attacks, the server maintains a store of jti values it has already seen. When a token arrives, the server checks whether its jti exists in the store. If it does, the token is rejected as a replay. If it does not, the server processes the token and adds the jti to the store. The store only needs to retain entries until the token's exp time passes, after which the token would be rejected on expiration grounds anyway.
Storage considerations:
The main challenge with jti tracking is the storage overhead. For high-traffic systems issuing millions of tokens, maintaining a complete jti registry requires significant memory or database capacity. Redis with TTL-based expiration is a popular solution because entries automatically expire when the corresponding token would have expired. Bloom filters can reduce memory usage at the cost of a small false positive rate.
When to use jti:
Not every application needs jti. It is most valuable for one-time-use tokens (like password reset links), financial transactions where replay could cause double-spending, and high-security environments where token theft is a significant concern. For standard API authentication with short-lived access tokens, the cost of maintaining a jti store may outweigh the security benefit.
Use Case
A banking API records each token's jti in Redis with a TTL matching the token's expiration, rejecting any repeated jti to prevent duplicate transaction submissions.