You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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());
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
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!
The text was updated successfully, but these errors were encountered:
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 :)
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:
Note that the introduction of another setter instead of changing
setAdditionalClaims
signature is to keep backwards compatibility. The newly introducedsetAdditionalComplexClaims
could support either a Map or a wild card (?
) type, with validations happening during thebuild()
call. I am open to both approaches and any recommendation would be welcome.Also not that because of the above a change on
JwtCredentials
is also required replacing the following code when generating the JWT payload:getAllAdditionalClaims
would be a map combining bothgetAdditionalClaims
andgetAdditionalComplexClaims
. 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
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!
The text was updated successfully, but these errors were encountered: