Facing issue with Verify JWT Policy

[priya_Edupalli]

Dear Team,

I am facing an issue with Verify JWT.

I am able to see verified payload in trace but at the same time, it is in showing invalid token in the trace and as well as in the postman console. For more details please find the below screenshot

Can anyone please help me with this.

Thanks,

Priyanka

[dchiesa1 · Accepted solution]

yes.  Check your keys.

There are a variety of reasons why VerifyJWT might declare that a JWT is invalid. The fact that you can see the payload in trace does not tell you that the JWT is valid.

Remember, a signed JWT is a string with three parts, separated by dots. HEADER.PAYLOAD.SIGNATURE

Each part is base64url-encoded. What this means is that any app or system can base64-decode the payload and "see it". We can call this "decoding the JWT." But normally, apps or systems want to do more than simply decode the JWT. They want to validate that the signature is correct for the JWT, and that the JWT is not expired, and that some expected claims in the JWT are present, and match expected values. All of that, we can group under the category of "verifying the JWT". That's what the VerifyJWT policy does.

VerifyJWT can return a "not valid" result when:

1. the JWT is expired, or is otherwise not valid w.r.t. issue time and not-before time.
2. the JWT is signed by a key that does not match the key used to verify
3. the JWT signature is corrupted or modified
4. the JWT payload or header has been changed
5. The inbound JWT uses an unacceptable signing algorithm 
6. an expected claim in the JWT payload or header is missing, or does not match the configured value

In the simple case, the JWT is expired or not-yet-valid. VerifyJWT can see that the signature matches, but the times on the JWT mean it should not be trusted. In this case VerifyJWT sets the "jwt.POLICYNAME.error" context variable to am English-language string indicating "the token is expired" or something similar. In the case of failing the check on the nbf claim, the message in that context variable might be "the token is not yet valid." It's possible for clock skew to lead to this result. If the issuing system has a clock which is skewed from the actual time, then it can issue a JWT that is not yet valid, or already expired, when that JWT is evaluated on a computer that has a good clock. So you always want to check the clock skew if you are getting surprising "expired" or "not yet valid" results.

I can see in your screenshot that the time remaining on your JWT is ~59 minutes. So the JWT in your case is not expired. Also I don't see anything related to the "nbf" claim. So that probably does not apply either.

That leaves the other cases I cited above. Cases 2-6. Just considering cases 2, 3, and 4, the symptom for each of these at runtime will be the same:  the policy will check the signature and find that it does not match. and the "jwt.POLICYNAME.error" context variable will contain a message like "invalid token".  That is the message you see in your case. There is no way for the VerifyJWT policy to distinguish between cases 2, 3, and 4. To diagnose and distinguish these, you need to investigate and test and take care to not modify the JWT between the time it gets issued and the time it gets verified. In my experience, the most common case is ... case #2.  You're using the wrong key. Double check that.

Case 5 - you will see the context variable "jwt.POLICYNAME.error" context variable containing the phrase "algorithm mismatch" or similar.

Case 6 - you will see the context variable with a message like "missing claim XXX" or "claim XXX does not match expected value" or similar.

You're not seeing messages like that. The message you're seeing is consistent with cases 2, 3, or 4.  Of those, case #2 is the most common problem.  So I would suggest that you check your keys!

BTW, here is an online tool that can help you work with signed JWT, trying out different key pairs, etc: https://dinochiesa.github.io/jwt/