Google-api-dotnet-client: JWT is not yet valid

[bschaeublin]

Hi there

Im using asp.net core 2.0.3 with "Google.Apis.Auth" 1.33.0.
I'm validating the id token of google+ with GoogleJsonWebSignature.ValidateAsync

It does work fine on my local Windows development machine, but it doesn't work on my debian jessie server.

situation

Time snapshot before i start signin with google+:

Console: Debian Server in Germany
Windows Client in Switzerland

Both at Monday, May 14, 2018 00:00, BUT:
the servers time is 7 seconds behind my client time

signin process

At 00:00:19, at the debian server, i request the jwt token from google
At 00:00:20, at the debian server, I received the jwt token from google, which contains following iat:

At 00:00:20, at the debian server, i received following log entry

xyzserver api[16255]: Google.Apis.Auth.InvalidJwtException: JWT is not yet valid.

conclusion

It looks like the IAT is 2 seconds after my server time, thats why the validation fails.
If im using the validation endpoint (which everyone tells you should not), it does works.

What would be the best practice in that case?

• Should i implement a custom IClock interface, which syncs with google's time server?
• Should i use the validation endpoint?
• Should i try to fix the servers time?

Thanks

[chrisdunelm]

Fixing the server time is definitely the correct option. Configuring it to sync with an decent NTP server should be sufficient; e.g. https://developers.google.com/time/ or http://www.pool.ntp.org/en/

[bschaeublin]

@chrisdunelm, thx I'll try that then - looks like seconds matter :D

[chrisdunelm]

Hmm, yes, we might consider adding a clock tolerance setting, to allow for a few seconds of server/client clock difference.

[andyfmiller]

I occasionally see the same issue. My local machine time drifts slightly ahead of the Google auth server and I see "JWT is not yet valid." Yesterday my local time was less than 1 second ahead of payload.IssuedAtTimeSeconds.Value. To get around that during dev, I've added 5 seconds of tolerance,

            var nowSeconds = (clock.UtcNow - UnixEpoch).TotalSeconds;
            if (nowSeconds < payload.IssuedAtTimeSeconds.Value - 5)
            {
                throw new InvalidJwtException("JWT is not yet valid.");
            }

[bschaeublin]

Just a thought: Does Google actually provide tokens, which are only meant to be valid after some time?
What would be the max value (not valid before) that google supports? Just asking, because it seems this check hurts more than it actually contributes to security?

If there would be added some tolerance, the question would be: "how much".

[worthy7]

Just ran into this issue too, the amount of problems I've had with google's dot net API, I may aswell have just written it all myself.

[chrisdunelm]

@bschaeublin I don't know if Google ever provide "future" tokens, but I don't think we'd just want to ignore the issue time.
To implement this we'd probably add an IssuedAtClockTolerence property to ValidationSettings, and default it to something like 30 seconds; but this could be changed by your code if required.

@andyfmiller @Worthy7 Thanks for commenting that you are also seeing this issue.

[worthy7]

Could we try to get this released ASAP please? I cannot do any work at home. I even synced my clock with time.google.com lol

[chrisdunelm]

This has been released in v1.34.0, available on nuget.org