Google and OAuth 2.0
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
Tue Apr 29 16:38:22 UTC 2014
On 4/29/2014 11:17 AM, Ben Bucksch wrote:
> neandr at gmx.de wrote, On 28.04.2014 20:10:
>> Lightning hides that process from the user.
>> That access key will be used to generate a token to work with your
>> mail/calendar. That token will expire after a certain time and your
>> application (mail/calendar) needs to generate a new token. Normally
>> the user should not notice about that for any session.
> Expiry indeed is a core problem. One-time setup - if it's really once
> and then never again - can be handled differently than something that
> can up at any random time.
> How does that process work? All readable documentation I found about
> OAuth speaks about webpages. That is: not HTTP URLs, but random HTML
> served by Google, containing arbitrary challenges to the end user
> (e.g. enter phone number, Google sending a code there, enter that
> code) that only the allowed human can fulfill.
Google's OAuth documentation is extremely heavily geared to web
applications. It's confusing even when you know what you're looking for. :-(
> If tokens can expire and be refreshed by Lightning without (!) user
> interaction, I don't know how that would work. Can you expand, please?
The authorization procedure looks like this:
1. Client makes authorization request to Google.
2. Google does authentication using its own UI and pages.
3. Google sends client an authorization code.
4. Client uses authorization code to gain an access token and refresh token.
5. Client sends access token to actually get access [this is the only
part that actually goes over IMAP].
6. Access tokens expire after a "short" amount of time (hours?)
7. A client can obtain a new access token with its refresh token. This
is meant to be saved in long-term storage.
There's this gem of a note:
"Note that there are limits on the number of refresh tokens that will be
issued... You should save refresh tokens in long-term storage and
continue to use them as long as they remain valid. If your application
requests too many refresh tokens, it may run into these limits, in which
case older refresh tokens will stop working."
[which, incidentally, turns out to contradict earlier statements on that
page about refresh tokens. Google's OAuth documentation is less than
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
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning