Google and OAuth 2.0
Joshua Cranmer 🐧
Pidgeot18 at gmail.com
Fri Apr 25 18:47:41 UTC 2014
On 4/25/2014 12:10 PM, Andrew Sutherland wrote:
> On 04/25/2014 12:35 PM, Joshua Cranmer 🐧 wrote:
>> Oh, and IIRC, OAuth requires you to provision a "secret" identifier
>> for your application, which is rather hostile for open-source
>> applications since checking it into our public repository is not
>> likely to go over well. :-(
> From https://developers.google.com/accounts/docs/OAuth2#installed:
> "The process results in a client ID and, in some cases, a client
> secret, which you embed in the source code of your application. (In
> this context, the client secret is obviously not treated as a secret.) "
I know that Firefox was requested by Google to hide its Google API keys.
>> OAuth 2.0 makes some amount of sense if your application only cares
>> about talking to Google's server. For a generic IMAP client, it is
>> really hostile to your userbase. I find Google's attempt to make
>> traditional authentication steps (even relatively secure SASL steps?)
>> more difficult for users to use to be rather hostile to users and
> I think this is unfair. A user's Google account is potentially a
> gateway to a mountain of personal and private information and a
> username/password is a fairly blunt instrument. While it's very
> possible to make a case that Google's application-specific passwords
> should support scoping so you can say "this password is just for
> gmail", that's effectively what their oauth2 implementation
> accomplishes, and with arguably better UX since it allows Google to be
> the entity describing to the user what abilities they are granting to
> Thunderbird if the user says yes.
(Reads documentation a little more closely)
Okay, at the very least, Google's documentation is completely horrid: I
didn't realize that it was possible to recover the bearer token without
having to scrape UI from a webpage.
I don't disagree that external authorization mechanisms are necessarily
a bad thing. However, I think that OAuth fails to be an effective mechanism:
1. The mechanism is trivial to internalize: you need to be able to
control an HTML form and http[s] calls manually, which isn't a terribly
hard task for many applications [e.g., Thunderbird's current OAuth 2
accesses do this]. Once you internalize the authorization, you still get
the username and password and effectively complete access.
2. Critical authorization tokens are passed in plaintext on URIs. So if
you can sniff this URI somehow, even without full control over the
authorization, you can still do large worlds of hurt. And URIs are
generally handled far more carelessly than, say, POST data.
3. There's no standardized way to access the authorization mechanism. In
GSSAPI, to request access an IMAP access token, you load a platform
library [typically], and you call an RFC-standardized function with
RFC-standardized parameters that indicate that you're looking for an
IMAP access token. In contrast, the SASL OAUTH step just has the client
access with a Bearer token it got from... who knows? The server, pages,
request parameters, etc., are never hinted at in the authentication
step, so the only way you can know these values are to manually hard
code them for every site.
It's #3 that makes me so resistant to this feature.
Thunderbird and DXR developer
Source code archæologist
More information about the tb-planning