After version 0.12.x, the JWT sub field is mandated to use the string type, which has led to failures in the service's JWT generation and verification.

[yutoutang]

Hi~

After our project upgraded jjwt to version 0.12.x, we found that the new version of jjwt enforces validation of the sub field in the payload to be of string type. This has caused failures in our JWT generation and verification, as our current JWT payload's sub field is of long type.

Background: We provide a general authentication service for developers, which covers a large number of applications and users. If we hastily modify the JWT generation rules, it will lead to incompatibility issues for the callers. Meanwhile, it would be very difficult for us to notify all callers to troubleshoot and rectify the problem.

Is it possible to enable the JWT issuance method where the sub field is of long type?

[lhazlewood]

Hi there!

The JWT RFC mandates (requires) that the sub field is a String value - anything other than a String violates the specification, and JJWT >= 0.12.0 enforces this.

That said, there is a way to address this, even if it is a little bit of a pain:

You can 'intercept' the JSON payload by customizing the JSON deserialization process: You can write a custom JJWT Deserializer to inspect the value, and upon seeing a long, wrap it in a String before JJWT 'sees' the value. Then the RFC validations will pass.

An example to do this is here: #958 (comment)

Then in your Java code, you can get the string and parse it as a long if you absolutely need to, e.g.

String sub = jwt.getPayload().getSubject();
Long id = null;
try {
    // legacy long value:
    id = Long.parseLong(sub);
} catch (NumberFormatException ignored) {
  // sub is a string and RFC-compliant, we're good
}

This way, your code is also explicit documentation on why you may need to support values that violate the RFC.

I hope that helps!

[lhazlewood]

P.S.

Another technique is to add the long value under a different Map key in the map returned by Jackson (or Gson, etc) before returning from the Deserializer.

For example, in the FixedKidDeserializer example shown in #958 (comment), you could do something like this:

private Map<String, ?> normalize(Map<String, ?> deserialized) {
    @SuppressWarnings("unchecked") Map<String, Object> map = (Map<String, Object>) deserialized;
    Object value = map.get("sub");
    if (value != null && !(value instanceof String)) { // not RFC-compliant, cleanup:
        map.put("legacySub", value);  // <----
        map.put("sub", "" + value); // make RFC-compliant
    }
    return map;
}

Then your Java code can do this:

Long legacySub = jwt.getPayload().get("legacySub", Long.class);

You can do any of this translation logic by customizing the Jackson ObjectMapper (or Gson equivalent) directly if you don't want to implement JJWT's Deserializer interface. Whatever is easiest for you.