add some leeway for checking JWT expiry, to account for clock skew

Description :

I have an error cause by a clock skew of one second between my hasura server and my JWT service (Firebase) . I think that it beneficial to allow a little bit of leeway in the validation of the iat of the token to let this kind of situation.

Error message :

{name: "FormatedError", message: "Unknown error", originalError: "cannot start as connection_init failed with : Could not verify JWT: JWTIssuedAtFuture"}

Solution :

Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Use of this claim should be OPTIONAL.

[tirumaraiselvan]

Hey folks

This commit: https://github.com/hasura/graphql-engine/commit/c14bcb6967c6dec1188a71432968a203007ec371 adds a new config allowed_skew in the JWT config to provide for some leeway while comparing the JWT expiry time.

This is planned to be released in v1.3.4 and you can configure clock skew according to your requirements.

NOTE: When you face this error, please do verify that the timestamp in the token and time in graphql-engine (according to logs) is suffering from clock skew and not some other issue.

[cstlaurent]

This issue is happening to all our developers using windows machines with Hasura in Docker for Windows running in WSL2… Machines and WSL are properly synchronized with NTP and happens with JWT token issued from Firebase and also Auth0.

To bypass this issue we have to manually set WSL clock 1 hour in the future on every boot, which is cumbersome.

No trouble on Docker for Mac…