Support Map as an additional claim on JWTClaim payload

[rafaelmenta]

Currently JwtClaims only support String objects when passing a map of additional claims. This limitation prevent applications that need more sophisticated JWT payloads to use the library.

According to the RFC 7519 a claim value can be any valid JSON value including numbers, booleans, dates, list and other objects.

An example of this feature being implemented can be found on this commit for the library java-jwt, by auth0.

Code snippet

This is how usage would look like:

Map<String, String> value = ImmutableMap.of("foo", "bar");

Map<String, String> stringClaim = ImmutableMap.of("fooStr", "barStr");
Map<String, Map<String, ?>> mapClaim = 
    Collections.<String, Map<String, ?>>singletonMap("zaz", value);

JwtClaims claims = JwtClaims.newBuilder()
        .setAdditionalClaims(stringClaim)
        .setAdditionalComplexClaims(mapClaim) // [NEW]
        .build();

1. Note that the introduction of another setter instead of changing setAdditionalClaims signature is to keep backwards compatibility. The newly introduced setAdditionalComplexClaims could support either a Map or a wild card (?) type, with validations happening during the build() call. I am open to both approaches and any recommendation would be welcome.

2. Also not that because of the above a change on JwtCredentials is also required replacing the following code when generating the JWT payload:

// used to be  payload.putAll(jwtClaims.getAdditionalClaims());
payload.putAll(jwtClaims.getAllAdditionalClaims());

1. getAllAdditionalClaims would be a map combining both getAdditionalClaims and getAdditionalComplexClaims. This would allow current users who set their claims through the original method to keep their code functional.

External references such as API reference guides used

• RFC 7519
• java-jwt library implementation

Any additional information below

Should this issue be accepted I'm willing to move forward with the implementation suggested above and create a Pull Request contributing to the library. Please also advice if there's any recommendation for the item (2) on the list above.

Thanks!

[chingor13]

Thanks for opening this issue!

Would we also need to have a List version? It seems that a claim value can also be a List.

Perhaps we would want to consider an overload like:

// import com.google.api.client.json.GenericData;

GenericData genericData = new GenericData();
genericData.put("key1, "string value");
genericData.put("key2", List.of("value1", "value2"));
GenericData nestedData = new GenericData();
nestedData.put("foo", "bar");
genericData.put("key3", nestedData);

JwtClaims claims = JwtClaims.newBuilder()
        .setAdditionalClaims(genericData)
        .build();

[rafaelmenta]

Hi Jeff,

Agreed, if we decide to add List we may as well support all additional types (numbers, booleans, dates, etc).

I will play around a little bit with how it would look like if use GenericData for overloading but my guess is that it would end up on a breaking change on the getter method, do you have any thoughts on that?

The alternative would be the additional setter/getter getAdditionalComplexClaims receiving a GenericData and a getter that merges them both so we can keep functionality on current users, similar to what I originally proposed.

Let me know which way sounds more appealing to you and I will have a PR soon :)