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:
>> http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html 
>>
>>
>> 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 
> now:
> 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): 
> <http://mailman13.u.washington.edu/pipermail/imap-protocol/2014-April/002243.html>. 
> 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 
> resolved.
>
> 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.
>
A follow-up:

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, 
DoGSSAPIStep2, etc.
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 
IMAP.

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 
standardized variants.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist




More information about the tb-planning mailing list