Google and OAuth 2.0
asutherland at asutherland.org
Mon Apr 28 21:41:41 UTC 2014
On 04/28/2014 10:58 AM, Gervase Markham wrote:
> * What does Google hope to gain by making this change? Is it an
> anti-spam/anti-fraud measure?
My interpretation is that this is about user account security.
I've got a long-form response here because these are relevant issues to
the Gaia email app that merit documentation, and I'm going to scavenge
from this message to provide the documentation / rationale.
## 2 Factor Auth ##
Google wants people to use 2-factor auth
clients need to continually establish new connections and perform
periodic synchronization without direct user interaction. This requires
some type of persistent credential.
(Without a persistent credential the user would need to continually
enter a new password that is the concatenation of the user's actual
password plus a currently valid code received via SMS or a Google
Authenticator/TOTP mechanism. I assert this is effectively
unworkable in the face of establishing new connections. It also leaks
the user's password, thereby reducing overall security.)
Use of single-factor authentication (just a password) that is used by
both the user and all their applications is
OAuth2 is one of two ways Google currently uses to provide a persistent
credential to applications. The other is "application specific
### OAuth2 / Account Permissions ###
OAuth2 can be used without enabling 2-factor authentication on an
account. It provides a persistent, revocable credential that is
explicitly scoped/controlled access to subsets of the user's Google
Account. The requested access is described by Google to the user at the
time of the request but it's a yes/no situation; the user can't
authorize a subset of access to the account.
In my quick test just now, the explanations were presented as high level
descriptions of the requested capabilities accompanied by little "i"
icons to the right that pop-up more detailed descriptions when you click
on them. When authorizing the currently Google Chrome-based whiteout.io
app, the Google-hosted dialog I got listed the following requests with
the given elaborations.
* View and manage your mail
** View, manage, and permanently delete your mail in Gmail
** Create, update, and delete labels
** Compose and send new email
* Know who you are on Google
** This app is requesting permission to associate you with your public
* View your email address
** View the email address associated with your account
Note that since I was already authenticated to Google so I did not need
to enter any credentials. And to reiterate, the page was served by
Google in Google's origin with frame-busting, although they clearly
support a mechanism for plugging in branding in a few spots.
A user interface to list existing authorized applications, their
authorizations is accessible from the user's Google account's "Security"
tab/page from the "Account Permissions" portion of the page. That
portion links to documentation at this page:
The page list capabilities grouped by Google product and reuses the
top-level descriptions from before, but does not provide access to the
tool-tips. So the breakdown for whiteout.io is:
** View and manage your mail
* Basic account info
** View your email address
** Know who you are on Google
A revoke button is provided and the date of the original authorization.
No additional data/metadata is currently surfaced in the UI.
### Application-Specific Passwords ###
These are unscoped credentials that require that 2-step verification be
enabled. The user manually creates an application-specific password
from their Google account's "Security" tab/page in the "Password"
section under "App passwords". The docs at
https://support.google.com/mail/answer/1173270?hl=en do a great job of
illustrating how it works, so I'll skip doing that.
These accomplish much of what the OAuth2 provided credentials provide,
and it is my understanding that :BenB is okay with these and thinks they
may be an acceptable workaround. Their deficiencies are that they:
* Are unscoped, which means that even though you may have created the
password for Thunderbird to access your email, if compromised it could
potentially be used to download all of your pictures that you uploaded
It's not immediately clear how Google handles these on the back-end.
They could be clever and realize you only ever use them for email and
then auto-scope them under the hood, or not. They could restrict them
to API endpoints, or maybe if you type one into any interactive login
prompt as your password it bypasses all 2-factor checks.
The biggest concern is that older versions of Android used
application-specific passwords and on an Android tablet I upgraded
Android was able to turn the application-specific password into a "Full
account access" "Account Permission(s)". It is possible there were
additional safe-guards in place like the device providing a sort-of
secondary factor to prove it was the device on file.
I should point out that Google does have it in their power to make
these credentials scoped. But then there's a new set of problems where
the user doesn't set the right permissions for the app / the required
permissions change / the user blindly pastes in some opaque set of
permissions / etc.
* Bad UX, significantly worse on mobile than on desktop, though it
varies on the mobile platform. Basically intractable on Firefox OS
because of our lack of copy and paste.
* Makes it harder for Google to react to zero-days on software / web
sites. One upside to OAuth2 is that since the application is required
to claim to be a specific piece of software/website, Google has the
ability to disable credentials on a per-application basis quickly across
all their users.
For example, let's say it turns out that there's a buffer overflow
attack on Thunderbird that allows an attacker to steal your
credentials. Google could invalidate all of the Thunderbird tokens as
soon as they find out and refuse to mint any new tokens for software
that claims to be that version of Thunderbird. Thunderbird registers
for a new secret and pushes out a security update with a fixed
Thunderbird and that uses the new credential
Note that there are also downsides to requiring applications to
register to get the not-really-secret secret key. It does not scale
unless there's an effort to create a community registry of applications
that other OAuth2 providers can pull from.
One could also make the argument that it makes it easy for Google to
deny access to Thunderbird. But practically speaking, there's nothing
stopping Thunderbird (or any client) from lying about what client it
is. And also it's fairly easy for Google to fingerprint Thunderbird's
IMAP/SMTP behavior if they wanted to systematically prevent Thunderbird
from accessing their system.
> * Can the additional data about logins that Google hopes to obtain be
> obtained in other ways for IMAP?
I'm not sure exactly what piece of information is being asked about
here. I think there are two possibilities:
* Google wants your phone number. I just went to create an account from
scratch, and while the form asks for a mobile phone number, the
documentation linked to from the page at
https://support.google.com/accounts/answer/1733224?hl=en says it's optional.
I think Google's rationale here is sound, but I do agree with Ben
that Google may potentially do other things with that information that
are not as much in the user's interest.
* Google's documentation explicit provides other mechanisms that don't
require the mail client to also be a web browser / have a web browser.
See https://developers.google.com/accounts/docs/OAuth2#device and the
greater details at
this is still OAuth2 and possibly even a somewhat Google-specific.
Given that Thunderbird is unlikely to already have google.com
credentials embedded inside it via cookie, triggers a different web
browser for general web browsing, and the mechanism does now allow data
to be passed back, this might be the ideal solution for Thunderbird.
In a broader contest responding to :BenB's answer here, I'll quote
myself from https://bugzilla.mozilla.org/show_bug.cgi?id=849540#c20 (and
omit a distracting point I retracted in a subsequent comment):
In terms of error messages, gmail actually already does this. They
provide a structured specific error code that software can identify,
plus they include human-readable text and a link to a support document.
Frequently not the world's best support document, but a good starting point.
A big problem with these error messages is that most servers provide
useless, unlocalized, confusing error messages so email clients have an
incentive to not show the error message directly to the user.
> * Why can't single-service passwords continue to be used instead?
It's not clear that they are eliminating application-specific
passwords. It'd be great if someone could find this out exactly. It
would not surprise me if they phased them out in the future or began to
more aggressively limit what they could access.
> * Do they understand the ramifications of the idea that clients of all
> these protocols will need to contain a browser? (Is that actually so?)
https://developers.google.com/accounts/docs/OAuth2#device as mentioned
> * Are there any ramifications on open source software in particular?
> (Seems from the discussion that the answer is actually no, but we need
> to be sure.)
No. From a message I sent earlier in the thread:
"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.) "
> * Who are the other desktop email software providers, and what are their
* The Firefox OS Gaia email app will be implementing this.
* The whiteout.io client (https://whiteout.io/) already does this, as
alluded to above. While under development, they are notable in that you
create or import a PGP key as part of the account setup process and the
app will try and upsell your unencrypted recipients to adopt PGP. The
app is in an early stage and is currently GMail-specific and operates as
a Chrome app and unfortunately although you can install the app via the
inline install mechanism (versus the chrome app store which does require
the browser to be bound to your Google account), actual account setup
does require binding to your Google account. Hopefully they change that
in the future, but you can at least tell Chrome not to sync stuff with
the server and to wrap it with an additional pass-phrase that is not
your Google credentials.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning