Google and OAuth 2.0

Ben Bucksch ben.bucksch at
Tue Apr 29 16:51:34 UTC 2014

Joshua Cranmer 🐧 wrote, On 29.04.2014 18:38:
> It's implied that refresh tokens both don't expire and will expire 
> over a "long" period of time, but the documentation is really vague on 
> this matter.

As Patrick said, the refresh token probably expires after weeks.
Even if it doesn't, Google may kill it for other reasons, e.g. you 
changing IP addresses.
This, an app needs to be prepared to refresh (re-gain) the refresh token 
and start from scratch at any time.

And yes, Google is *intentionally* vague. That's policy: They want to be 
in full control.

That means we'd need to handle 4 different tokens: Auth token, refresh 
token, access token. Plus the password that the user enters towards Google.

Any of them can suddenly go invalid at any time for any reason. If 
you've ever implemented something like that, it's gruesome. Esp. given 
that you need to be able to go back to UI at any time, and the 
documentation and error codes are intentionally vague, it's hard to make 
a proper design. Often, you can't even distinguish between expiry and 
auth failure, due to collation of error codes, so it's hard to know what 
to do, and you risk doing loops.

(And given that we display the browser and have control over it, we can 
get the password, making the whole thing moot, as you pointed out. For 
that exact reason, for me, token-based auth mechs are all security theater.)


More information about the tb-planning mailing list