Google and OAuth 2.0
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
Thu May 29 03:04:05 UTC 2014
On 4/30/2014 1:47 PM, Joshua Cranmer 🐧 wrote:
> On 4/25/2014 10:52 AM, Gervase Markham wrote:
>> Is this relevant to Thunderbird accessing Gmail?
> This was brought up in the status meeting, and we resolved to reach
> out to Gmail to clarify some questions. Here's the status of as right
> 1. The clarification from GMail IMAP folks is:
>> The bottom line is that GMail would really like Thunderbird to use
>> OAuth2 for imap/smtp/pop access. If it doesn't, there's an increased
>> possibility that GMail will suspect the login attempt is
>> unauthorized. If you keep using the same IP address, or have two
>> factor auth turned on, you'll most likely be OK. Otherwise, the users
>> run the risk of having to jump through some hoops to get imap access
>> again (I don't know the exact details of that...)
> 2. I've made a post to the IMAP-protocol list about this topic (it
> felt more relevant there than the Kitten working group):
> From responses in the past 12 hours, it does seem like there is
> agreement by client implementers that some of these issues need to be
> 3. I've been told by both Bienvenu and Brandon that the OAuth people
> have been brought into the discussion, although they haven't responded
> publicly yet.
> It looks to me that it will be possible to see many of the concerns I
> have about OAuth discussed and addressed.
> As a side note, it also looks like other IMAP servers are planning on
> supporting OAuth 2.0. Outlook.com recently rolled out support for it
> as well, and I think there was another server the name of which I
> don't recall right now.
1. The OAuth working group is currently producing a document on dynamic
client registration. This satisfies one of my two principle concerns.
Reading up on ancillary information, Thunderbird was explicitly
mentioned as a use case. I've read the current draft, and my thoughts
are best summarized as:
* We may need to provision a public/private key pair for Thunderbird. I
don't know how secret this would need to be, but since a key pair is all
that's needed, it's a relatively simple matter to generate one locally
for developers. Perhaps even automatically ^_^
** [Note: keys here are JWT keys, if that means anything to anybody else.]
* There may be some slight issues with localization. There's provisions
for displaying localized strings, but it's not quite clear to me what
the recommended best practice is. Worst case scenario may require us to
carry several localizations at once.
* We'll get a client id and a client secret. May be useful for other
OAuth 2.0 uses in our tree.
* Yet another endpoint
I don't see any major issues, but I'll read it more thoroughly when a
last call is put out.
2. There was some discussion of the issues at the Internet Identity
Workshop, which apparently happened basically the week after this thread
started. This gives a little bit of background context on some of the
design choices, and Thunderbird is explicitly mentioned as the IMAP/SASL
dynamic client registration use case. \o/
3. Endpoint discovery is mentioned several times as a concern... and
mentioned several times as a deferral. I'm concerned that the kitten
[SASL] and OAuth working groups aren't necessarily talking to each
other, because there's an off-hand comment by someone that perhaps SASL
could elucidate the endpoint information, yet the OAuth SASL spec is in
last call and explicitly disclaims responsibility for endpoint notification.
I don't follow the working groups myself, but I've binged on their
archives for relevant details.
So, what should we be doing?
1. This has been discussed in another circumstance, but moving the OAuth
2.0 to shared code or toolkit is probably a good first step.
2. We ought to tweak our SASL code to not assume that SASL is
synchronous. This might also be an excellent time to attempt to
consolidate the SASL code into a better framework than DoGSSAPIStep1,
3. OAuth 2.0 as a SASL backend is almost certainly going to be in JS.
IMAP protocols are off-main-thread, and hence are forbidden from direct
JS access. We need to make sure that we do a main-thread-proxy here for
I'm guessing that usable endpoint discovery won't roll out for 6-9
months, which means we may need to temporarily hardcode the endpoint
locations for, say, gmail. :-( OTOH, it also depends on how quickly
Google or other providers roll out implementations of the current
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning