auth.verify_id_token fails with 'Token used too early'

[fschaeck]

The function auth.verify_id_token may fail for tokens that were issued by servers which have clocks running a little early.

If verification is done right after the token was issued by such a server, then the call to function google.oauth2.id_token.verify_token in _JWTVerifier.verify in firebase_admin/_token_gen.py may be early enough for the 'issued-at-time' timestamp of the token still being in the future.

That will lead to the error 'Token used too early' from google.oauth2.id_token.verify_token, because the function _JWTVerifier.verify is not passing along the optional parameter clock_skew_in_seconds, which would make the google...verify_token function allow for slightly off clock settings.

The worst part about this is, that depending on the server's clock setting and the speed, googles verify_token function is called and the time it takes, to get the api request through to the verification server, the verification of such tokens sometimes may work and sometimes may not. Making this a very hard to understand - and account for - issue.

Adding the optional parameter clock_skew_in_seconds=60 to the call to google.oauth2.id_token.verify_token would allow for the servers clock to be off by up to a minute and still allow verification of the issued token immediately after it being issued.

Otherwise, developers working with firebase_admin's function auth.verify_id_token would have to add a slight delay before calling the function to account for such clock skew.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[siddie]

Any news? It's almost a year since the report and PR.

[foolishsailor]

crazy that this hasnt been merged yet?????

[omalave]

Try to set google ntp server as your datetime source. https://developers.google.com/time/guides

[GaryFrewin]

Is this ever going to be updated. It seems like an absolutely fundamental part of this package.

Firebase issues a token and then we try to use it immediately to get some information that the user needs on the front end, and they have to deal with errors because of a clock issue? Seriously? This request is a year old and is a basic and completely required piece of functionality.

What is going on?

[ccppoo]

I added

await asyncio.sleep(1)

[GaryFrewin]

I added

await asyncio.sleep(1)

This doesn't always work. I've tried various sleep times and anything up to 20 seconds can still fail.

I ended up building my own skew function to catch the error and parse out the times.

[ccppoo]

I added

await asyncio.sleep(1)

This doesn't always work. I've tried various sleep times and anything up to 20 seconds can still fail.

I ended up building my own skew function to catch the error and parse out the times.

@GaryFrewin

this happens when system clock is not synchronized

windows 11, in my case, I fixed with manually syncronizing system time (settings -> time -> synchronize now)

in docker and ubuntu(docker) containers I haven't met this issue for 2 months,

only on windows while developing

I could understand why firebase is so strict about time,

but it will be more nice if adding options for generous time lags for development purpose

[jonathanedey]

Addressed in #714