Badly formatted iat claim ignored by VerifyJWT

[supportapicentr]

We're using the VerifyJWT policy to unpack a JWT request token. use of "iat" in a request token is optional for our use case, but if it is present we want to verify that it has the correct format.

If I make iat a NumericString date as per rfc7519 (e.g. "1559255948000") It sets a variable called, "jwt.Verify-Request-JWT.claim.issuedat", behaving pretty much as expected.

However if I set the value of iat to a non-conforming string (e.g. "Thu, 30 May 2019 22:39:24 UTC") it ignores it and get no variable at all.

As a result I can't tell the difference between a missing iat element (valid) and a badly formatted iat element (invalid).

Has anyone else run into this? Is there a way round this behaviour?

[supportapicentr]

P.S. I haven't tested this for other claims, due to lack of time

[dchiesa1]

Is there a way round this behaviour?

What specifically do you want to do?

If you'd like to examine the iat claim directly, that should be possible. There should be a variable with a name like jwt.POLICYNAME.payload-json, which contains the json for the payload. In other words, something like this:

{
    "sub": "subject-here",
    "iss": "issuer-here",
    "jti": "jwt-id-123",
    "iat": "2019-05-31T22:30:00",
    "exp": 1559372400
}

You can then use ExtractVariables, or an AssignMessage with a jsonPath, or a JavaScript policy to look at the iat claim and then... do something when iat does not comply with the spec.

BTW, just clarifying regarding NumericDate, per RFC7519. The value in the JWT is given in seconds, while the context variable is currently set to a value expressed in milliseconds. ?? That is changing with the next release; the context variable will be set to a value expressed in seconds, just as the claim in the token. This is true for iat as well as exp and nbf.

[supportapicentr]

What specifically do you want to do?

Handle a badly formatted iat value as an error but allow either no iat or a valid iat.

One of my colleagues provided a solution for this actually. The VerifyJWT policy does provide a variable called, "payload-claim-names," which provides an array of just the names of the claims in the token. If issuedat is not present beause iat was badly formatted, iat still turns up as claim name in this array. So it if is present in the array and not present as a value we assume it was a value format error.