"Invalid Json" error due to duplicate "sub" (Subject) Claim in JWT

[vineeth.km mattanur]

It is observed that when JWT encrypted token contains customized “sub“ key in it, jose4j is adding an extra key “sub“ in the decoded json, and it results in InvalidJson error thrown by the library.

Below is an example where you can find duplicate key “sub“ in the decoded json. I tried with the latest version 0.7.6 of the library and still it is the same issue. We have also logged the JWT token before decoding and confirmed that it doesn't contain any duplicate keys.

Decoded token (“sub” is duplicated)

{
"exp":xxxxxxxxxxx,
"iat":xxxxxxxxxxxx,
"jti":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"iss":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"aud":"account",
"sub":"740d4527-37fe-4816-b95a-cee4d94368b1",
"typ":"Bearer",
"azp":"xxxxxxxxxxxxxxxxxxx",
"session_state":"xxxxxxxxxxxxxxxxxxxxx",
"acr":"1",
"allowed-origins":[
"xxxxxxxxxxxxxxxxxxx"
],
"realm_access":{
"roles":[
"xxxxxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxxxxx"
]
},
"resource_access":{
"account":{
"roles":[
"xxxxxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxxxxx"
]
}
},
"scope":"xxxxxxxxxxxxxxxxxxx",
"sub":"service-account-xxxxxxxxxxxxxxxxxxx",
"clientId":"xxxxxxxxxxxxxxxxxxx",
"clientHost":"xxxxxxxxxxxxxxxxxxxx",
"email_verified":false,
"preferred_username":"service-account-xxxxxxxxxx",
"clientAddress":"xxxxxxxxxxxxxxxxxxx"
}

[Brian Campbell]

It is true that software defects sometimes manifest themselves in unexpected or unusual ways. I’ve been surprised before and no doubt will be again. But I honestly don’t think that’s the case here and I’d humbly suggest that the likelihood that the library is actually adding extra duplicative claims to the JSON payload is vanishingly small.

As such, I’d have no idea how to go about reproducing this issue let alone ‘fix’ it. So, please provide an easily runnable bit of code that demonstrates and reproduces the issue.

[vineeth.km mattanur]

Thanks for your quick response.

We have now identified the problem. The issue was that the encrypted JWT token indeed contained duplicate “sub“ in it when it was generated, but then online tools like https://www.jsonwebtoken.io/ and jwt.io ignores the duplicate key and only use the last “sub“ property, hence the duplicate “sub“ was not visible when we decoded the token online. We understand that jose4j library is checking for duplicate key strictly and hence it fails.

You can close this defect.