JWT Claims Mapping

[jzheaux]

Summary

When a JWT-encoded claim set is handed to Nimbus, the claim set is decoded and then coerced into a chosen Java type for each claim. Specifically:

• nbf, iat, and exp are mapped to java.util.Date
• aud is mapped to java.util.List

Additionally, Nimbus allowed the temporal claims to be null, since the JWT spec allows for this.

Spring Security maps the above fields in the following way:

• nbf, iat and exp are mapped to Long
• iat and exp are given a default value
• aud is mapped to java.util.List

With both libraries, all other claims are left as-is, including custom claims.

For now, the work to transform the Nimbus representation into the Spring Security representation of the claims set is embedded into NimbusJwtDecoderJwkSupport, though at least a couple of concerns are likely to surface again and again with other implementations of JwtDecoder:

1. The need to map a third-party library's representation of the temporal fields to Long

This issue affirms that both Nimbus and Auth0's implementation of the JWT spec coerce the temporal fields into java.util.Date. There are likely more libraries that do the same thing, which will require devs to duplicate code that transforms those Dates into Longs.

2. The need to give exp and iat default values

NimbusJwtDecoderJwkSupport today wants to give exp and iat default values. If Spring Security intends to enforce this opinion in other implementations (for consistency), then the code needs to not be embedded in the Nimbus-specific implementation.

Actual Behavior

Certain shared logic is currently embedded in NimbusJwtDecoderJwkSupport.

Expected Behavior

Said logic should be in a more generic location.

Version

5.1.0.BUILD-SNAPSHOT