Google and OAuth 2.0

Joshua Cranmer 🐧 Pidgeot18 at
Mon Apr 28 22:44:56 UTC 2014

On 4/28/2014 9:58 AM, Gervase Markham wrote:
> * What does Google hope to gain by making this change? Is it an
> anti-spam/anti-fraud measure?

I think Google's goal is to be able to control the entire authentication 
process rather than delegating it to the normal protocol authentication 
(i.e., SASL) procedures. You might be able to argue that it's merely a 
means to other ends, but I get the impression that Google is too fixated 
on the OAuth 2 mechanism in particular to fail to ponder how best their 
goals, whatever they may be, may be best served in the normal SASL 
mechanisms. The more I think about the security implications of OAuth 
2-via-SASL, the more I see it as ultimately a weakening of security 
guarantees as far as IMAP is concerned.

Looking at OAuth 2 itself, it seems to me like a really, really insecure 
variant of Kerberos. I'm guessing the main reason they don't want to 
attempt to reuse prior art here is
a) They want to authorize the client in particular instead of the 
mechanism of access (which to me is bogus).
b) Using Kerberos may be "too hard" for people (despite having 
well-established, cross-platform support for at least a decade).
c) They want to eliminate the ability for the client to 
control/intercept authentication (which OAuth 2.0 only appears to do).

> * Can the additional data about logins that Google hopes to obtain be
> obtained in other ways for IMAP?

It probably shouldn't be hard to get most of the same functionality via 
1. KDC servers can already be looked up via DNS SRV records.
2. SASL/GSSAPI already gives a well-defined mapping to look up how to 
request a service ticket (e.g., imap/ at GMAIL.COM).
3. If they want to authenticate client id, they could arguably do this 
by having users login not with Pidgeot18 at GMAIL.COM but with 
Pidgeot18/ClientKey at GMAIL.COM.
4. Acquiring kerberos tickets is typically handled outside of the client 
anyways (if you select GSSAPI as the auth option, we don't bother asking 
for a password, although there is a bug on us popping up dialogs if the 
ticket expired).
> * Do they understand the ramifications of the idea that clients of all
> these protocols will need to contain a browser? (Is that actually so?)

The main ramification to me is not that clients need to contain a 
browser but that they need to encode gmail-specific logic with little 
pretense of genericity. Note that the "contain a browser" portion of it 
automatically implies in great detail that clients have complete control 
over the authentication/authorization process anyways, one of the 
reasons I think the security gains are rather illusory.

Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

More information about the tb-planning mailing list