Google and OAuth 2.0
ben.bucksch at beonex.com
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