Solved: "IgnoreIssuedAt" on VerifyJWT policy usage

luisfelipecosta · 01-22-2021 12:43 PM

Hello,

I'm trying to execute a validation on 2 sequencial tokens with VerifyJWT policy. The first token, a JWE, as recomended here. The second one, a simple JWT.

When using this configuration, the token seems to be issued at on the future, for no reason, and results as an error. When I remove the second VerifyJWT, it works.

For testing, I used the "IgnoreIssuedAt" element as true and both policies worked. Can someone help?

dchiesa1

I'm trying to execute a validation on 2 sequencial tokens with VerifyJWT policy.

I don't understand the significance of the information that these tokens are "sequential". Is that important?

the token seems to be issued at on the future, for no reason,

Because you are asking about VerifyJWT, I am inferring that you have tokens that have been generated by some other system, and the JWT has a "iat" claim that lies in the future.

You said "it seems to be issued in the future, for no reason." This can happen when the program that generates the JWT is in error. It can also happen when the clock on the computer that generates the JWT is not synchronized with the clock on the computer that verifies the JWT. If you use Apigee cloud, there is a computer in the cloud that runs the VerifyJWT policy. It has its time synchronized with an NTP server somewhere in the cloud. Unless something very very bad has happened, the time on that Apigee cloud computer is ... we might say, "known to be correct." Therefore, if you are using Apigee cloud, it is highly likely that "the other system", the system that generated the JWT, may have a time skew problem.

If you are using Apigee OPDK, then... it is possible that the machine that runs your Message Processor has an incorrect time.

BUT! It may be something quite benign. If the clocks are misaligned even by 1 or 2 seconds, still the VerifyJWT policy on Apigee can reject the inbound JWT as "Not Yet Valid".

Apigee's VerifyJWT policy has two mechanisms for handling such conditions: The IgnoreIssuedAt element and the TimeAllowance element. You can read about these in the fine documentation.

The IgnoreIssuedAt element, when present and set to "true", will tell the VerifyJWT policy to simply disregard the value of the "iat" claim, for the purposes of validation of the token. The actual JWT specification does not explicitly state whether verifiers should check the iat value during validity check or not. Apigee chose to have VerifyJWT check that value by default. This element lets you toggle that behavior in the policy. It looks like this:

<VerifyJWT name='VerifyJWT-IgnoreIssuedAt'>
  <Algorithm>RS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <Value ref='rsa_public_key'/>
  </PublicKey>
  <IgnoreIssuedAt>true</IgnoreIssuedAt> <!-- look here -->
</VerifyJWT>

I just tried this on my Apigee organization hosted in the Apigee cloud. A VerifyJWT that lacks the IgnoreIssuedAt element will reject a token that has iat in the future. A VerifyJWT that includes the IgnoreIssuedAt (And has the value true) will not reject a token if it has an iat in the future. (Though it may still reject the token for other reasons).

If you want to play around with this, you can use this online tool to create your own JWT with iat that lies some time in the future.

I used the "IgnoreIssuedAt" element as true and both policies worked. Can someone help?

If I understand the situation, then I think this is the way the IgnoreIssuedAt policy is intended to work. What is the problem?

View solution in original post

Report Inappropriate Content

In the first case it was checking the tokens issue time and it was find the second token issued after the first one in sequence.

When you set to ignore it doesn't check when the tokens issued, so it doesn't check the consecutive or not, it only validates the tokens are valid or not.

dchiesa1