Unexpected type of JSON object member with key "exp"

[sharathyeramall]

Hi There,

I am getting below error while verifying the JWT in apgee, I am using essentially RSA key(public/private) to verify the JWT signature, it appears it failing while signature verification. Could you pls she some light about the error.

Error: Unexpected type of JSON object member with key "exp"

[ylesyuk]

According https://tools.ietf.org/html/rfc7519#page-9, exp's s value MUST be a number

containing a NumericDate value.

To troubleshoot your jwt, trace a request, copy the jwt value and paste it into jwt.io. You will see what is your current value of the exp field.

[sharathyeramall]

I have a field called exp, which is the expiry of JWT i,e "exp": "1580680257"

[ylesyuk]

And here is the problem: your value is a string. it must be a number, i.e.:

"exp": 1580680257

[sharathyeramall]

Good Catch. But this jwt issued by a third party and trying to validate it @APIGEE, this is either failing during the decode policy too with the same error on exp. How to handle this situation at APIGEE.since its a legacy client can't be asked to perform any changes.Pls advice.

[ylesyuk]

Because you're using non-standard jwt, your non-standard jwt is signed with a key whose public key you have. It's pointless to manipulate your decoded jwt representation, because it will not be what is signed. For this reason, for your non-standard jwt, you must use non-standard verify jwt implementation.

Luckily, Apigee makes it easy conceptually: use Java Callout to implement your non-standard jwt verification.

Another stroke of luck, @Dino-at-Google makes it easy practically. Use his code published at https://github.com/apigee/iloveapis2015-jwt-jwe-jws as a starting point for your implementation.

[dchiesa1]

I have seen such JWT previously - in which the time values are actually strings. And we considered making the VerifyJWT policy lenient enough to handle such JWT. But in the end we decided that following Postel's Law here was not a good idea. The specification is pretty clear, and there's no strong need to violate the spec in order to satisfy a broken implementation.

Popleys, I suggest that you connect with the 3rd party that is issuing the broken JWT and point them to the specification, and ask them to correct their implementation.

[dchiesa1]

Another approach that may work is to verify the thing in question with VerifyJWS. The VerifyJWS policy does not validate claims within the payload - such as exp and iat. So you can use VerifyJWT to verify *just the signature*, then you would have to MANUALLY convert the exp and nbf claims from string to number, and then MANUALLY validate those times.

I haven't tried this but it should work. You wouldn't have to write Java code to do this; but you'd probably want to use JavaScript to do the custom validation of exp claims.