This has been live on our servers for a while, but is now announced and open for general use. Here’s the short version: If you have an Android app and a web-server back-end, you can authenticate the person using the app to your back-end securely, efficiently, and with no prompts or passwords.
I’m pretty happy with this, and think that app developers who can use this should. Because your server really has to know who it’s talking to, but there are few things less friendly to a person using a mobile device than making them type passwords.
The long version is a multi-step recipe, but nothing about it is actually difficult. I’m not going to revisit the recipe, but here are a few sidelights worth noting.
OAuth and OpenID · This is based on the OAuth 2 code that’s already built into the our back end and Google Play services. Which I think highlights what OAuth 2 really is: Not a real Internet Protocol like HTTP or SMTP, but a framework that you can use to build useful pieces of authentication and authorization machinery.
The technique is based on using an ID Token, a notion that actually comes out of OpenID Connect. So thanks to those people for cooking up this useful thing. We probably can’t claim that this is OpenID Connect-compliant, because, well, OIDC isn’t finished yet. But it probably will be eventually.
Limitations · This isn’t for 100% of everybody. It won’t work for you if:
You don’t want to use any of the Google accounts on the device, or
You’re on a device that doesn’t have Google Play or is running a version of Android older than 2.2 (Froyo).
Lots of developers want to support really old devices and also things like Kindles and Nooks. I suspect that the user experience in doing identity this way is superior enough that those people should probably implement this anyhow for the people that can use it, and fall back to old-fashioned passwords or whatever for the rest.
Account Selection Tricks · Every piece of code I’ve seen that talks about using Google identities on Android begins with a callout via the AccountPicker class to show a list of the accounts on the device and ask the person holding it to pick one.
But I think that can often be dodged. To start with, lots of devices have just one account; in which case you can just use it. Another option, if there’s more than one, is to (don’t laugh) just pick the first one and run with that. I do that in my LifeSaver application and nobody’s complained yet.
And if you must make them pick an account, remember it in a SharedPreferences or something for next time, so it’s a one-time tax.
Permissions · For this to work, your app needs to be able to retrieve a user’s email address, and talk to Google’s auth servers. So it needs two permissions: GET_ACCOUNTS and INTERNET.
Contributions
Comment feed for ongoing:
From: Jeffrey Yasskin (Jan 08 2013, at 10:27)
Sorry if this is a dumb question, but is there a fundamental reason this can't use non-Google accounts? A Kindle could presumably have an Amazon account, which could be an OpenID source as easily as a Google account.
[link]
From: Randy (Jan 08 2013, at 10:44)
"Another option, if there’s more than one, is to (don’t laugh) just pick the first one and run with that."
If you aren't doing much that might be okay.
However, if your app picks one of my Google accounts at random for an IAP without offering me a choice, there's a 50% chance you just lost that sell and it is extremely likely I'll uninstall soon after.
I'm not interested in my Play data being spread across multiple accounts nor do I want credit card information on them all.
[link]
From: Jeremy (Jan 08 2013, at 11:27)
If there is more than one account, then please let me choose (don't guess that the first one is the correct one to use). I have personal and work accounts on my Android devices, and want & need to keep them separate.
[link]
From: Jan (Jan 08 2013, at 11:54)
If I understand correctly, this shares the (gmail) email address with the app and implicitly authenticates without a password being shared with the app. Can you confirm that the user gets a popup "inside" the app before the account is shared the first time?...
[link]
From: Peter Phillips (Jan 08 2013, at 12:02)
Certainly a nice addition.
I see your official Android Blog entry mentions game high scores. A good example, but it reminds me that Google should be providing a complete service for high scores, achievements etc.
PS3/Wii/XBOX all have these services but the most relevant examples would be Amazon's Game Circle and Apple's Game Center.
OpenFeint would be relevant, too, except it is defunct and GREE hasn't finished their Android offering.
[link]
From: Anders (Jan 08 2013, at 12:08)
Hallelujah! The best part is this (from the Code Fragments on the bottom of the page you linked to):
> If you wanted to do this in Ruby,
> you’d want to install the
> google-id-token Ruby gem, and do
> something like this:
The Ruby code sample is like one-billionth that of the overly verbose Java code!
Congratulations!
[link]
From: Tim (Jan 08 2013, at 12:59)
Hey @Jan, if you read the details, it turns out that the way this is set up, we can know that the android app and the web app are from the same developer. So we consider that if they've agreed to give their address to the app, they're OK with sharing it with the same developer's back-end.
[link]
From: JB (Jan 08 2013, at 15:06)
@Tim, RE Jan's comment about sharing the email, wouldn't it be better to not share the email but rather share a unique per-app token comprised of e.g. HASH(EMAIL + APP_TOKEN)?
I'd think that most apps don't really need email, just identity.
Also, using this, theoretically it should be possible to retrieve a token to be used as an unlock key?
e.g. I have a password safe on my device which is very difficult to actually unlock due to the limited keyboard.
So the app could theoretically be changed to store an encrypted copy of the PW for the file on (preferably encrypted) storage which would then be decrypted by either the pure token returned from GoogleAuthUtil or a combination of token and short PW that would be easier to enter on a handset.
Cheers
JB
[link]
From: Tom (Jan 08 2013, at 16:33)
I like this both as a developer and as a user.
However, if a user buys my app and then installs it on their phone and tablet (for example), it is important that my server associate both instances of the app with the same account.
I think this same concern is reflected in some of the other comments above.
I believe that each device has a single account associated with the Play store - that is the account that I want to use. If Android could return that account first when I enumerate accounts - or give me some other way to figure out which is the 'play store' account - then the problem would be resolved without my having to prompt the user.
[link]
From: Ivan Sagalaev (Jan 08 2013, at 23:53)
The bit about "Oauth is not a protocol" prompted me to share my own post from a while ago about this same thesis: http://softwaremaniacs.org/blog/2012/07/30/oauth-is-not-a-protocol/en/
Hope it's useful.
[link]
From: Brendan Larson (Jan 19 2013, at 14:38)
Tim and company,
Nice work, keep it going! Am also glad to see Google is experimenting with Yubikeys < http://goo.gl/qcuAE >
-Brendan
[link]