Google and OAuth 2.0
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
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/mail.google.com 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
> * 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.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning