JWT "BeforeValidException" error in "verifyIdToken"

[bshaffer]

The following code occasionally throws a "BeforeValidException" error:

$authResponse = $client->fetchAccessTokenWithAuthCode($code);

if ($client->getAccessToken()) {
    $userInfo = $client->verifyIdToken();
    // .. proceed to do stuff with the user info
}

Here is the full stack trace:

BeforeValidException in JWT.php line 112:
Cannot handle token prior to 2016-02-02T13:01:09-0800
in JWT.php line 112
at JWT::decode('eyJhbGciOiJS...', array('RS256')) in Verify.php line 89
at Google_AccessToken_Verify->verifyIdToken('eyJhbGciOiJS...') in Client.php line 682 

[bshaffer]

fixed in #828

[gulachek]

Sign in with Google randomly started throwing this at me. Can someone add an explanation for what configuration needs to be watched out for either to this issue or to the documentation for verifyIdToken? Or is this a bug in the google client software? It's odd that the same code has been working for a year but now is suddenly consistently throwing this message, but as soon as I refresh my sign in with google "data-login_uri" with the same post request that threw the error, the token verification succeeds. This seems like a bug to me, but I'm open to being incorrect.

I'm happy to provide more context/details, but I want to see if someone is on the other end before putting that effort in.

[gulachek]

For future readers: I decided to dig in to the implementation/RFC to figure this out more quickly.

TL;DR The firebase php-jwt JWT implementation has a nonstandard check to verify that "the time according to the JWT on the issuing server" is not later than "the time on the machine that is verifying the JWT", w/in some apparently statically configured leeway. I believe this check in itself is a bug, sleeping until the 'iat' time in the payload to sync the machine time offsets seems like a sad but doable workaround in the meantime.

More details:

The firebase php-jwt JWT.php has this line:
// Check that this token has been created before 'now'. This prevents
// using tokens that have been created for later use (and haven't
// correctly used the nbf claim).
if (isset($payload->iat) && $payload->iat > ($timestamp + static::$leeway)) {
throw new BeforeValidException(
'Cannot handle token prior to ' . \date(DateTime::ISO8601, $payload->iat)
);
}

According to the RFC:
The "iat" (issued at) claim identifies the time at which the JWT was
issued. This claim can be used to determine the age of the JWT. Its
value MUST be a number containing a NumericDate value. Use of this
claim is OPTIONAL.

Notice that it says nothing about validating that this timestamp is not "in the future according to the validating machine's time". Enforcing this in the JWT.php code seems like an issue, as I've already seen (it looks like the Sign In With Google server is off by about 2 seconds with my machine). It's unreasonable to assume that it's a server maintainer's fault for getting out of sync with google's server's timestamp. I think library should be interpreting 'iat' in the future as an indication of this server offset to potentially offset the \time() return value instead of assuming they should be in sync +/- some leeway. I think the next step is to submit a bug to the repo for php-jwt, and I don't think this is an issue with google-api-php-client, but I hope my analysis might be useful for a few people who stumble upon this from a google search. :)

[bshaffer]

Hi @gulachek ! Thank you for your comment on this. I will follow up in the issue you filed here: firebase/php-jwt#475