Google and OAuth 2.0

Andrew Sutherland asutherland at
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 
(  IMAP/SMTP-based 
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[1] 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 
passwords" (

### 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 
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 
Google profile.
* 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 is:

* Gmail
** 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 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 
via Picasa.

   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 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 and the 
greater details at However 
this is still OAuth2 and possibly even a somewhat Google-specific.  
Given that Thunderbird is unlikely to already have 
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 (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?) 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
> opinions?

* The Firefox OS Gaia email app will be implementing this.

* The client ( 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...
URL: <>

More information about the tb-planning mailing list