I’m using auth0 in a spring boot application (micro services architecture) with security.
One of the micro services in my application logs itself in, automatically and calls other services in the application that require authorization.
Every once in a while a token will get a “401 unauthorized” error. after may attempts to debug this i eventually logged the token and used it manually to access the service using postman… first few calls will get the 401 error but eventually the token will go through… i have no idea how this behavior is even possible or where to begin to debug / fix this.
Any help on this matter would be much appreciated!
In general, JWT access tokens will have not just an expiration date, but also a not before date which means that libraries performing the access token validation can reject the token if that not before date is in the future.
At this time, access tokens will not be issued with not before dates in the future, however, if your server machines do not have a time synchronization service then their clocks can drift and consider that the received access token has a future not before date. This would explain why after a while the access token is accepted (the computer clock just continued until the its notion of current time is enough to accept it).
The recommendation is that server machines performing token validation should have a NTP service configured.
Thank you for this information! i did not know that about ‘not before date’.
Just to make sure i understand - you’re saying that ‘clocks’ across my services are not fully synced which in turn can cause them to think they are not allowed to use a token just yet?
As for NTP - i understand the concept but not quite sure how it will remedy the situation…
Also - do you know of any Spring boot related implementations i can look at (for NTP)?
On another matter - is it possible to simply disable this ‘not before date’ on auth0?
The most likely explanation would be that the system clock in your system is not synchronized correctly and as such has some deviations from the system clock of the system used to issue the token (the Auth0 service). Synchronization needs to be done at operating system level so it would not be specific to Spring Boot, but to the underlying OS (Windows, Unix, etc).
To my knowledge there is no way to disable it in Auth0 and right now the service will always issue tokens containing a claim that indicates when was the token issued which then results in libraries rejecting tokens that from their perspective were issued in the future. However, some JWT validation libs allow you to disable certain validations which would have a similar end-result as they would just consider the token valid if the only thing wrong with it was the issuance date in the future thing. Ideally, instead of disabling it you could allow a certain leeway; depends on lib support.
Thank you again for all the detailed information. I think there’s another issue that lays here… the access_token iat is epoch time GMT and my OS is GMT+2, so based on what you are saying i shouldn’t be able to use any of my tokens for 2 hours (in case future tokens are not allowed) but this is not the case. When i manually login to my system via postman and adding the token to my service calls header (which takes probably just a few seconds) i’m authenticated successfully. but when the batch does it (probably in less than a second to login and make the call) it gets the 401 error.
So both calls (the manual one and the automated one) are executed from a GMT +2 with a GMT token… i’m not sure where to take it from here honestly… 
The timezone should (excluding validation libraries with bugs) be irrelevant. The issued token contain the date in UTC and the validation library should be taking the local time in whatever timezone that is and convert it to UTC for validation purposes. In general, what leads to these issues is time synchronization problems in the order of seconds… UTC time in token issue is 05:00:00 and time in consumer machine is 06:59:05+2 which would get converted to 04:59:05 UTC which would still mean the token was issued in the future due to the 55 seconds diff.
I had the same issue on an Ubuntu server running timesyncd (which is default). I was under the impression that this was a solution that replaced the need for ntp entirely, but apparently it’s not as accurate.
sudo apt-get install ntp and a reboot solved the issue completely.