4 ms·
If it's unverified, then you can't trust the header to begin with. You can't trust that it even forms any kind of valid format. It could be a payload of "naught
by shakna 6y ago
If it's unverified, then you can't trust the header to begin with. You can't trust that it even forms any kind of valid format. It could be a payload of "naughtystrings" for all you know.
And if you really must decode it, then you can call the base64 decode yourself - and know what you're doing is unsafe.
In the case of an unverified token, it is best to pretend the token doesn't even exist.
- will4274 6y agoLiterally incorrect. You can't verify the jwt prior to reading the header, because you don't know which of the advertised keys was used to sign the jwt. Check out e.g. auth0's doc. https://auth0.com/docs/tokens/json-web-tokens/validate-json-web-tokens https://auth0.com/docs/tokens/json-web-tokens/validate-json-...
- shakna 6y agoI assume you're refering to this part of the spec: > If the JOSE Header contains a "cty" (content type) value of "JWT", then the Message is a JWT that was the subject of nested signing or encryption operations. In this case, return to Step 1, using the Message as the JWT. [0] This is also step 8 of validating a JWT. There is a number of validation steps you need to take before you can decide how to process the payload. You'll also note that none of the previous 7 steps actually decode the payload ("the Message") - they only find it. And 4 of those steps are about verifying that the header isn't dangerous. [0] https://tools.ietf.org/html/rfc7519#section-7.2 https://tools.ietf.org/html/rfc7519#section-7.2