Jwt-auth: Not Before (nbf) timestamp cannot be in the future error

[SimonErich]

hey guys,

just had a strange problem where I got the above mentioned error when trying to login to one of our platforms for no reason.
After a bit of debugging I found the problem and it seemed to have been caused by the switch to standard time here in Austria. (just between 02:00 and 03:00)
I just waited it out to confirm it was indeed that and now everything works fine again.

I have two reasons for dropping it here:
1.) if someone has a smililar problem and googles for that.
(since I couldn't find anything about that)

2.) What could that be or how could I avoid that next time we change times to summer again?
Is it maybe a problem with server or computer time?

thanks

[szpakol]

Confirming - same issue in the UK. Definitelly need to l

[BasConijn]

The timestamps are stored in UTC.
I checked the IsFuture function and they seem to use UTC times as well.

[tuskla20]

Is anyone still seeing this? I am getting this error intermittently with no changes to our code or systems just popped up after the time change. We have verified that the time and timezone on all servers match

[f7n]

Anyone?

[marczahn]

Get this as well - Even with setting the nbf manually to the past. And it is not reproducable deterministcally.

[ThiagoLovatine]

I still have this error, on my vps's it's working fine, but now I have to publish in the client's production server and I can't make it work

[feelinc]

I'm having the same problem with Europe/London timezone, working correctly when setting a different timezone.

Can someone explain why using "Carbon::createFromTimeStampUTC" in "Tymon\JWTAuth\Utils"?

[ekstremedia]

Time changed tonight and now im getting the same error too.

[ekstremedia]

@feelinc Changing to
return Carbon::createFromTimestamp($timestamp);
in Utils.php temporarly fixed the problem for me

[feelinc]

@ekstremedia yes done that too, thanks.

[bhanushalimahesh3]

me too facing this error, any update on it apart from temporarily fixed by @ekstremedia ??

[kmuenkel]

Can anyone explain what the intended purpose of this 'Not Before' (nbf) value is? The description is "The earliest point in time that the token can be used", which makes it sound like placing this date in the past would render it moot. But at the same time, Tymon\JWTAuth\Validators\PayloadValidator::validateTimestamps() had a check on the date making sure it's not in the future.

[kmuenkel]

I found a reliable hack around this. Whenever you create your tokens, just leverage the customClaims array to set 'nfb' => 0. Without fully understanding what the purpose of this value is though, I can't promise it won't have other ramifications.

UPDATE: Sorry, apparently this solution did not work, I'm still getting the same problem. Will update again if I figure it out.

[joeltay17]

I faced this error when I have a project set up over 2 servers (In amazon, there are 2 EC2 instances, load balanced by an ELB). These servers have a time difference of 7 seconds. So if i was unlucky, first API call will hit the server with the later time, and then 2nd API call will hit the other server with the earlier time.

Patching the time on both servers will eradicate this error.

@kmuenkel hope u had figured it out by now haha

[jamiehd]

Not sure if this should be a separate issue as its a slightly different cause, but we've been having an issue where our server times were out by a few milliseconds. This means a token issued by one server but used on another would sometimes throw this error as it was technically used before it was issued.

This has only become an issue since Carbon added milliseconds support to their library.

I have fixed it by changing validateTimestamps in PayloadValidator to do this:

if (isset($payload['nbf']) && Utils::timestamp($payload['nbf'])->subSecond()->isFuture()) {

And the same for the iat check.

I would suggest adding something similar to the library as one of the big uses of JWT is so servers can share tokens, and as there is no way to guarentee server time will be accurate to within a millisecond I could see this being an issue for others.

@tymondesigns I am happy to submit a PR for this if you would agree for it to be merged?

[tymondesigns]

@jamiehd there is a leeway option in the config for this exact purpose https://github.com/tymondesigns/jwt-auth/blob/develop/config/config.php#L211

[jamiehd]

@tymondesigns I did not realise this! Thanks very much :)

[abbood]

@tymondesigns the leeway variable of DatetimeTrait.php is acting up. It is randomly reset to 0 sometimes. See more details in this SO question

[jamiehd]

@abbood were you using refresh tokens? I don't think those have the leeway passed in from the config. I reported this in #1714

As for your stackoverflow post - traits are not static. They do not share their state among all instances - each one binds its properties to the class that uses it.

[abbood]

@jamiehd No i'm using the Authenticate middle ware not the refresh token one.

I'm using this for my unit tests, and my tests some times pass and sometimes fail randomly on authentication (i specifically migrated my jwt from 0.5.4 to 1.0.0-rc just for the leeway config)

I put these logs in the code.. notice the pattern:

   │ string(96) "method setleeway exists for iat setting leeway to 5000on claim: 00000000628b970200000000595c4585"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
  │ string(96) "set leeway: 5000 on object: 00000000628b970200000000595c4585Class: Tymon\JWTAuth\Claims\IssuedAt"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
  │ string(27) "get for: [exp],[1661270432]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:83:
  │ string(96) "method setleeway exists for exp setting leeway to 5000on claim: 00000000628b970500000000595c4585"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
  │ string(98) "set leeway: 5000 on object: 00000000628b970500000000595c4585Class: Tymon\JWTAuth\Claims\Expiration"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
  │ string(27) "get for: [nbf],[1566662432]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:83:
  │ string(96) "method setleeway exists for nbf setting leeway to 5000on claim: 00000000628b970400000000595c4585"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
  │ string(97) "set leeway: 5000 on object: 00000000628b970400000000595c4585Class: Tymon\JWTAuth\Claims\NotBefore"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
  │ string(33) "get for: [jti],[RCVhLKcd7YHJsE4n]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:86:
  │ string(78) "method setleeway DOES NOT EXIST FOR jti claim:00000000628b970600000000595c4585"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
  │ string(33) "get for: [iss],[http://localhost]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:86:
  │ string(78) "method setleeway DOES NOT EXIST FOR iss claim:00000000628b970400000000595c4585"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
  │ string(27) "get for: [iat],[1566672872]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:71:
  │ string(113) "calling is future with leeway :0 on object: 00000000628b970500000000595c4585 Class: Tymon\JWTAuth\Claims\IssuedAt"

although object 00000000628b970500000000595c4585 belonged to the Expiration Claim, and 5000 was set to it, we later on call it on class Claims\IssuedAt but with a 0 leeway anyways!

Not sure how/why this is happening

[abbood]

The above is the failing example, here is a successful example from the same unit test:

[string(96) "method setleeway exists for iat setting leeway to 5000on claim: 00000000628ba7bc00000000595c4585"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
      │ string(96) "set leeway: 5000 on object: 00000000628ba7bc00000000595c4585Class: Tymon\JWTAuth\Claims\IssuedAt"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
      │ string(27) "get for: [exp],[1661270432]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:83:
      │ string(96) "method setleeway exists for exp setting leeway to 5000on claim: 00000000628ba7bf00000000595c4585"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
      │ string(98) "set leeway: 5000 on object: 00000000628ba7bf00000000595c4585Class: Tymon\JWTAuth\Claims\Expiration"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
      │ string(27) "get for: [nbf],[1566662432]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:83:
      │ string(96) "method setleeway exists for nbf setting leeway to 5000on claim: 00000000628ba7a100000000595c4585"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:97:
      │ string(97) "set leeway: 5000 on object: 00000000628ba7a100000000595c4585Class: Tymon\JWTAuth\Claims\NotBefore"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
      │ string(33) "get for: [jti],[9tYfDeiyRp3P6AtO]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:86:
      │ string(78) "method setleeway DOES NOT EXIST FOR jti claim:00000000628ba7be00000000595c4585"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
      │ string(18) "get for: [sub],[1]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:86:
      │ string(78) "method setleeway DOES NOT EXIST FOR sub claim:00000000628ba7a300000000595c4585"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:78:
      │ string(57) "get for: [prv],[87e0af1ef9fd15812fdec97153a14e0b047546aa]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:90:
      │ string(86) "does not have name, returning custom: [prv],[87e0af1ef9fd15812fdec97153a14e0b047546aa]"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/DatetimeTrait.php:71:
      │ string(116) "calling is future with leeway :5000 on object: 00000000628ba7bc00000000595c4585 Class: Tymon\JWTAuth\Claims\IssuedAt"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:68:
      │ string(39) "original timestamp: 2019-08-24 16:00:32"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:69:
      │ string(12) "leeway: 5000"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:70:
      │ string(43) "timestamp minus leeway: 2019-08-24 14:37:12"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:71:
      │ string(24) "now: 2019-08-24 16:00:32"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:72:
      │ string(24) "expected:: is future? no"
      │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Support/Utils.php:78:
      │ string(23) "actual::  is future? no"

](url)so unlike the failing example, we are calling leeway with a 5000 seconds from the same object Tymon\JWTAuth\Claims\IssuedAt where we instantiated it with. In the failing example we are calling a 0 leeway on a Tymon\JWTAuth\Claims\Expiration class. So it seems there is a race condition or something like that in the factory or something

note: i noticed over the tests that in the successful case we always get a prv claim:

  │ string(57) "get for: [prv],[87e0af1ef9fd15812fdec97153a14e0b047546aa]"
  │ /Users/Shared/dev/php/toters-api/vendor/tymon/jwt-auth/src/Claims/Factory.php:90:
  │ string(86) "does not have name, returning custom: [prv],[87e0af1ef9fd15812fdec97153a14e0b047546aa]"

not sure if this has to do with anything

[abbood]

Now that i'm researching online, I think i'm going over this the wrong way. For unit testing I should just impersonate the user or mock auth

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.