How to handle expiry when Authentication Server and Recourse server have different time zones

[mubasherusman]

My Authentication Server is in the Timezone UTC while the Resource servers are distributed microservices with different timezones, some have UTC+ and some have UTC- time zones.

Sometimes My Resource servers give expired token exceptions while the actual difference between
issueAt - expireAt < desired expiry time

This happened because the expiration date in the token was generated by UTC timezone while the library was comparing to the resource server's current time.

Is there a way by which I can override the expiry by ourselves as per our needs? The library should only check whether the signature is valid or not.

[bdemers]

The dates in a JWT are:

NumericDate
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

Because of this, the timezone of the local system should not matter. Are the clocks on your servers set to UTC or a localized time?
If possible you could run the command date -u from your server and see if you get the correct time returned.

[mubasherusman]

Yes, I know and you are right about NumericDate ... they are timestamps from 1970 ...
However, The Auth server that generates tokens is in UTC+00 But Resource Servers needs to set a particular geographic server date due to some other requirements. e.g. The microservice in Ohio have UTC-05 and the microservice in Japan UTC+09. This timezone difference with auth server cause the library to unexpectedly throw token expired exception.

While the difference between token issue date - expiry date is not more then 2 minutes.

The debugging revealed that this library compares the expiry date with resource server's time. in case of UTC-05 token is active for 5 hours. in case of utc+09 it ai always expired.

So I was looking a way by which I can provide custom Method/functional Interface which compare the issue date claim and expiry date claim and if difference is more then desired interval then throw expiry exception.

[bdemers]

Sorry, I'm not sure I understand. Are you saying there is an issue in JJWT or something you are trying work around in your environment?

Does your microservice running in Ohio, have it's system clock set to UTC-05? (or the actual UTC time)?
If the system clock is set to something else this would have potential problems for other security mechanisms too.

I would like to understand what is going on in more detail, but if this an environment issue you are working around, take a look at the Custom Clock section of the readme.

[mubasherusman]

@bdemers Hi, I apologize for the late response. I went on vacation.

Yes, Microservices has its own regional time setting to serve the content for the relevant audience. So time settings are at the instance/container level rather than converting by some interceptor/Filter against every request.

I have checked Custom Clock on your suggestion and it works. I have to initialize it based on the provided iat claim in JWTs.

[lhazlewood]

As @bdemers pointed out, you will probably want to use the custom Clock concept for the JWT Parser, and I think that will address your issue:

create your own io.jsonwebtoken.Clock implementation, and each time now() is called, return a Date instance that is adjusted (added or subtracted) by the number of seconds different from UTC time.

[lhazlewood]

I wanted to add a general comment that may or may not help you (given your specific company/project constraints), but I feel it is important for any casual readers that might come across this thread in the future:

Really, all clocks in all machines in a company's infrastructure should be tightly controlled to always be set to UTC when booting.

As someone supporting production architectures for 25 years, I can't tell you the number of times I've seen problems due to non-UTC clocks, from things like this, to log entry problems, telemetry and/or analytics confusion, application side-effects, etc. The amount of productivity lost due to this problem is insidious.

As such, applications, in their own code, and only when absolutely necessary, should convert any generated or stored timestamps from UTC to a local time zone at the time it is required, which ideally should only be in a user interface. For example, to show an end-user information in their own timezone.

Especially when security concepts exist, like in JWTs, you will save yourself a world of trouble, pain, and debugging/logging sessions if you standardize UTC everywhere.

If you're running infrastructure on AWS (for example), EC2 instances can be sync'd with microsecond precision (for free) using the AWS Time Sync Service on both Linux and Windows. Or otherwise just sync with well-known atomic clocks around the world.

I do understand engineers sometimes cannot control production infrastructure clock settings, but they should do everything they can to ask their management or customers that all system clocks are normalized to UTC whenever possible (and not just ignore the problem).

If not addressed, there will be downstream problems for the organization and/or projects over time. I've seen it SO many times.

[mubasherusman]

Really Appreciate the advice. We will look into how can we improve this once and for all. Thanks, a lot.