JWT Validation beyond Signatures
Using JWTs securely goes beyond verifying their signatures. Apart from the signature, the JWT can contain a few other security-related properties. These properties come in the form of reserved claims that can be included in the body of the JWT.
The most crucial security claim is the "exp" claim. The issuer uses this claim to indicate the expiration date of a JWT. If this expiration date lies in the past, the JWT has expired and must not be used anymore. A typical example use case is an OpenID Connect identity token, which expires after a set period.
A second related claim is the “iat” claim. This claim indicates when the JWT has been issued. It is often used to enable the consumer of the JWT to decide if the token is fresh enough. If not, the consumer can reject the JWT in favor of a newly issued one.
Third, JWTs can contain the "nbf" claim. This abbreviation stands for "not before." It indicates the point in time when the JWT becomes valid. A JWT can only be accepted if this timestamp lies in the past.
The fourth security-relevant reserved claim is "iss." This claim indicates the identity of the party that issued the JWT. The claim holds a simple string, of which the value is at the discretion of the issuer. The consumer of a JWT should always check that the "iss" claim matches the expected issuer (e.g., sso.example.com).
The fifth relevant claim is the "aud" claim. This abbreviation stands for audience. It indicates for whom the token is intended. The consumer of a JWT should always verify that the audience matches its own identifier. The value of this claim is again a string value, at the discretion of the issuer. In OAuth 2.0 and OpenID Connect scenarios, this value typically contains the client identifier (e.g., api.example.com).
Note that the specification mentions that all of these claims are optional. Nonetheless, it is highly recommended that your application includes them when issuing JWTs. Similarly, their presence must be verified when validating JWTs. Doing so can help prevent abuse when the JWT is exposed one way or another.
Below is a code example of how to verify these claims using the popular “java-jwt” library. As you can see, the library offers dedicated functions to verify these claims. Check your libraries to find out how to optimally handle these claims.
Algorithm algorithm = Algorithm.HMAC256(HMAC_KEY);
JWTVerifier verifier = JWT.require(algorithm)
.withIssuer("sso.pragmaticwebsecurity.com")
.withAudience("api.pragmaticwebsecurity.com")
.build();
DecodedJWT verifiedJWT = verifier.verify(token);
// Get the subject
verifiedJWT.getSubject();
