Unable to parse claims without key

[ravi-prajapati-1995]

Before version 0.12.0 we are able to parse claim in JWT without using key like: Jwts.parser().parseClaimsJwt(jwtWithoutSignature). Is there any alternative if I am using version 0.12.0 or later, I just want to parse claims and I am using algorithm RS256 for.
As I documentation there is method parseUnsecuredClaims() but it is only valid if we have alg: none.

Please suggest me alternative of parseClaimsJwt

[bdemers]

This question comes up from time to time.
From a security perspective this is bad idea and violates the RFC, the first line of the JWS RFC:

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures

The RFC also goes on to say this about the alg header param (section 4.1.1):

This Header Parameter MUST be present and MUST be understood and processed by implementations.

Ignoring the alg header or processing it differently would not aline with these statements.

---

That said I'd still like to understand your use case. Why do you want to parse the token if you cannot be assured the content is valid?

Have you validated the token some other way? Do you not have access to the public key?

I'd like to keep the discussion going, but if you want a quick and dirty answer....

A JWS (signed JWT) is formatted in 3 parts: <header>.<payload>.<signature>
If all you care about is the <payload> section, you could just strip the other parts off and use a JSON parser.
If you want to use a JWT library to parse the token (maybe you still want to validate other claims?).

You could remove the signature section, and replace the header.
Try this out on https://token.dev/

Start with the token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTcwODAxNzEwNCwiZXhwIjoxNzA4MDIwNzA0fQ.ixyrJBMS7txcLJJQ6hxVmarcE8IVD2jqbSvNJl5IWj4

Remove the signature:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTcwODAxNzEwNCwiZXhwIjoxNzA4MDIwNzA0fQ

Then replace the header with eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0 (the header for a non-signed JWT) and you could parse it with a JWT library

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTcwODAxNzEwNCwiZXhwIjoxNzA4MDIwNzA0fQ

Notice that the middle section of the original JWT did not change in the last block

You can base64 URL decode it and you would see:

{"sub":"1234567890","name":"John Doe","admin":true,"iat":1708017104,"exp":1708020704}

Important

The decoding of the payload is the easy part, the heavy lifting (and the important part) performed by JJWT is dealing with all of the security related concerns around tokens.

[claudevervoort]

I think this may be related: we need to get the iss to lookup the associated keyset. kid is in the header, iss in the body, that's how we verify the token is issued by the issuer (signed with a key registered with the issuer). We're using version .10 so that works fine (the resolver passing both the header and the claims), but hitting a bit of a roadblock trying to upgrade since the locator is only now passing the header.

[lhazlewood]

Hi @claudevervoort !

Please take a look at #857

and specifically this comment.

TLDR: we'll try and find a longer term solution for this, but per the RFC channels and the new RFC that is in draft, anything that you need from the claims that is required for key lookup should be repeated in the header. The body (claims) shouldn't be trusted until after signature verification.

[claudevervoort]

Oh thanks for pointing it out! It does make sense that the header should be self sufficient to locate the key. However the specification we use requires (issuer,clientid) -> keyset mapping (there could be hundreds of those in the context of integrating with many schools, as each school can be their own issuer), so that would be a breaking change to that specification (1edtech LTI) to mandate issuer and client id being repeated in the header. In addition it would force that information to be crossed check with the actual payload once parsed (same issuer, clientid in header and payload). 🤔

[lhazlewood]

Understood, but read #857 in depth. Whatever specification you're referencing (1edtech LTI?) is fundamentally breaking the security model of JWS - that spec committee should be notified, as it's a poor practice (they're also ignoring the jku and other header parameters that exist specifically to address these issues).. Also see the RFC best practices recommendation document linked in the comment above.

JJWT only implements and adheres to the JWT RFC specifications, not any other specifications built on top of JWT. That said, we'll do our best to come up with a solution, but that's only fixing a problem that should never have existed in the 1edtech LTI specification to begin with. The authors of that spec are introducing risk to its implementors.

[claudevervoort]

I'll bring it up to the 1ed tech folks, going to be an interesting debate. Thanks for all the background on this and your work on this library!

[bdemers]

@claudevervoort Take a look at the JSON Web Token Best Current Practices

Many of those topics covered in this doc should be codified in other specs that consume JWTs
For example, see the "Validating JWT Access Tokens" section in JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

[claudevervoort]

One more question if you're ok to entertain that thread a bit more: https://datatracker.ietf.org/doc/html/rfc7519#section-5.3
This mentions that it's ok to replicate claims like iss in the case of encrypted JWT... which means it's ok to have it only in the payload if just signed. Is it intended to be further restraint in follow up RFC, or just best practices?

[bdemers]

You could do that, the key thing is you cannot trust anything in the header until after you verify the token.

Say you add the iss to the header. You would then need to compare it's value to a known allow list of issuers. If the value is not in the list, stop processing the token. If it is in the list, then you use a previously arranged key (or public key lookup from a previously known location), to verify the token. (In JJWT this logic would happen in a custom Key Locator.)

[claudevervoort]

Right, and then cross check the header issuer with the one in the payload. I understand the use of the iss in payload is not prohibited in the case of signed JWT, and thus it looks like there is not enough ground to introduce a major breaking change in the openid derived spec that is 1edtech LTI. In any case, i brought up that discussion for consideration. Thanks again for your insights!

[lhazlewood]

@claudevervoort just for posterity, it's not exactly 'ok' to have key-identifying information only in the JWS payload per https://www.ietf.org/archive/id/draft-tschofenig-jose-cose-guidance-00.html

The takeaway is that the RFC committee basically agrees that information should not really be read in the payload until after signature verification or AEAD decryption, but that it is too late to change any of the now-finalized RFCs (which is why https://www.ietf.org/archive/id/draft-tschofenig-jose-cose-guidance-00.html exists, as an addendum).