Disabling validation of "sub" claims in 0.12

[alexmdac]

My system needs to accept JWTs that have numeric values for "sub" (a numeric user ID). I cannot migrate the system from jjwt 0.11 to 0.12 because 0.12 rejects JWTs with "sub" claims that are not strings. I understand that numeric "sub" claims are invalid per RFC7519, but unfortunately the system needs to continue to accept old tokens for many more months. Is it somehow possible to configure 0.12 parsers not to check the type of "sub" claims? If not, would it be possible to add such an option?

Thank you.

[lhazlewood]

Hi @alexmdac !

I think your best option here (and I think it's a pretty good one IMO), is to use a custom Deserializer implementation that wraps/delegates to the real JSON processor Deserializer (Jackson, Gson, etc), and coerce the non-compliant values into a RFC-compliant String before JJWT ever interprets those values.

One such way of doing that is described in this comment:

#958 (comment)

Granted, that particular issue was about a non-String kid, but the same logic/principle applies for a non-String sub value as well.

Then JJWT and your application will see a String as expected, and you can parse it back into an integer if necessary. It's a little bit of a pain, but it's pretty seamless. It also ensures via internal application code and/or documentation, why you have to do something unexpected due to non-compliant JWT issuers, which is a good thing IMO for future developers and/or code inspection.

Plus it gives you a 'hook in' point to do further transformation if you ever receive other non-compliant values.

I hope this helps!

[lhazlewood]

P.S. Another approach is to perform this logic is, instead of using the JJWT Deserializer approach discussed above, is to use Jackson's API directly by implementing a custom Deserializer as shown here:

https://www.baeldung.com/jackson-deserialization#on-mapper

where you inspect the node and change the data type of a value for only the node IDs you care about. And then you register that custom deserializer with your Jackson ObjectMapper.

It just depends on which of the two APIs you want to implement. A custom Jackson deserializer (instead of a JJWT one) would make a lot of sense if you need to customize/compile using Jackson-specific concepts in other parts of your project already, otherwise JJWT's API might be easier since you'd be just working with a Map instead of JSON Node semantics.