Migrating user accounts from Google OpenID to Google OAuth to Google Plus

Background

Over here, Ade has asked me to permalink a comment I made about moving Player FM accounts from Google Open ID to OAuth. The reason I did it was because Android sign-in is really based on OAuth, but what I didn’t know was Google at the time was preparing to launch “Sign in with Google Plus”, also based on OAuth. Bottom line: Google Open ID, afaict, is going the way of the dodo, so any services using it probably want to migrate their users to G+. (Googlers may please correct me if I’m wrong about Open ID’s demise.)

There were many permutations to be considered for this kind of migration, each with trade-offs to developer complexity and user experience. What follows was the optimum balance for me after a repetition of thought experiments, in between wishing I had a pony (ie that I’d opted for OAuth in the first place, the only reason I didn’t was availability of an Open ID Rails plugin). This is all web-based as we (thankfully) hadn’t launched on Android yet.

The problem

The first concern here is largely about user perceptions. To us developers, Google OAuth and Google Open ID are distinct login mechanisms, as similar to each other as they are to Facebook or Twitter. But to the user, they’re the same thing – Googles all the way down. So you can’t present the user with separate login buttons for Google OAuth and Google Open ID…you only get to present one Big G button.

The other concern is that sites who present “Existing users – log in here” versus “New users – sign up here” buttons … are doing it wrong. A major benefit of third-party sign-in is you can just present a “Connect with X” button and the user doesn’t have to care or remember if they previously connected with X or not. Don’t make me think!

Put concern A together with concern B and Houston, we have a problem. You present that one big G button with Google OAuth and what happens if the user is unrecognised? Is this a new user or someone who had previously logged in using Open ID. (It’s fine if the user is recognised, that means they’re one of the post-OAuth-era people.)

The solution

The solution depends if you’re willing to ask for email permissions on the new oAuth flow.

If you are willing to ask for email, that will make it easy to link the two accounts, because Open ID already relies on email, so you have their email. You can just switch right now to oAuth and once the user authenticates, link the account with the account having the same o8 ID. (Note: this scenario is purely speculative and not based on my experience.)

Since I chose not to ask for email, I had to do the uncool thing and temporarily divided Login from Signup.

In the Login area, the app prompted users for their email or login, and immediately made an XHR call to detect whether that account is using o8 or oAuth, then showed the corresponding button (the button is just a Google button, looks the same either way but the link will be different for o8 vs oAuth). (In addition, the Twitter and classic login form were shown.)

For people who logged in with Open ID, I built an !IMPORTANT! big red notification when the user logged in via Open ID, telling them we’ve updated Google login procedure, and when they click to set it up, taking them through the oAuth flow with a special callback for the migration. At this point, the server recognises the two accounts are linked (they’d already logged in with Open ID, now they’ve just logged in with OAuth), so we can save the user’s OAuth credentials. This user now has two third-party accounts – Google Open ID and Google OAuth. Just as they might also have a Facebook account and a Twitter account.

The Signup area of course only contained an OAuth button (as well as Twitter, which was exactly the same as Twitter in the login area, and classic signup form).

I published advance notice on the blog I would be shutting down the old Google IDs, kept the migration alive for two months, and then deleted all the Open ID accounts at that time. Anyone who didn’t log in at the time lost their accounts, but of course a few people mailed me about it (mainly when we launched the Android app and they tried to log in again), so I helped them migrate manually.

I did this for a couple months before deprecating o8 and returning to the nicer single Google button setup. And just manually merged the accounts when a few users asked me why the Google button is not getting them back to their old account.?

Epilogue

It was well worth the pain, as the vast majority of Android users now choose to log in with Google, even though we also support classic login and guest mode. The G+ API was a big bonus to come out of it. I’ve done some experiments on the social side and expect to do much more with G+ accounts in the future, to help people discover new shows to listen to.

Discovering Users’ Social Path with the New Google+ API

Google announced a slew of identity and social updates today, most excitingly, the ability to browse users’ social paths. This happens after similar services recently blocking some folks from doing so, which tells you Google gave it due consideration and is committed to supporting this feature indefinitely.

Here’s how the authentication looks:

Now there’s a whole set of widgets and JavaScript APIs, but I was interested in the regular scenario for apps already using the “traditional” OAuth 2 dance. After asking on the G+ APIs community, I was able to get this running and I’ll explain how below.

Step 1. Visit the API doc: https://developers.google.com/+/api/latest/people/list

Step 2. Scroll to the interactive part below and turn on OAuth 2.0 on the top-right switch.

Step 3. To the default scope, add a new one: https://www.googleapis.com/auth/plus.login. That’s the magic scope that lets your app pull in social graphs.

Step 4. For userID, enter “me”. For collection, enter “visible”. (This collection property, representing circles/people the user can identify to the app, only has that one value at present.)

Step 5. Now hit execute and (as a test user) you’ll see the dialog shown at the top of this article. Then hit accept.

Step 6. I got a confirmation dialog saying “Clicking Confirm will let Google APIs Explorer know who is in your circles (but not the circle names). This includes some circles that are not public on your profile.” which is surprising as I believe circles are always private (for now), so I guess users will always see that. Accept it.

Step 7. The JSON response will now be shown below the form. It includes a top-level field called “items”, which is the list of your (the authenticated user’s) G+ people. If the list is too long, there will also be a “nextPageToken” field so the app can page through the list.

So that’s an overview of the new G+ social API. It’s a straightforward OAuth implementation and should be easy for anyone with a Google login to adopt. I’ve been looking forward to adding this functionality on Player FM so people can see what their friends are listening to … I think it’s a nice model where users can choose how much of their social graph they share with any app.

FireEagle Developer Event

FireEagle

I discovered at last minute a developer event on Yahoo! FireEagle at Covent Garden tonight and decided to rush down there. FireEagle is pretty intriguing as the first serious attempt at an OAuth API (though Google Contacts now qualifies too). For me, that was the main draw; but the actual service it offers is also compelling.

What’s FireEagle?

Location based services have been hyped for years. By now, you should be walking around and receiving reviews of local restaurants on your phone, browsing nearby tourist attractions, and seeing which of your friends is in your vicinity. However, it hasn’t caught on. The main reason is stovepipes and walled gardens. Your mobile provider might have an API available, but probably restricted access to a very limited set of developers. A mix of privacy and commercial concerns have rendered this whole area practically useless.

Enter the eagle. FireEagle completely opens up this area, by offering a model that is flexible and open, but without compromising user privacy. It’s an API that essentially tracks one thing: Where in the world are all FireEagle users?

In other words, the FireEagle API allows any client to update a user’s location and any client to retrieve a user’s location. Of course, the user must consent to all this activity, and that’s where OAuth comes in – as a way for users to say, for example, “I trust app abc to update my location and app xyz to read my location”. So FireEagle detaches location providers from location consumers, opening up an entire ecosystem.

What kind of clients act as location updaters? You might think it’s all automated stuff, like mobile devices and IP numbers, but actually many updaters are manual. Here’s a sample:

  • Mobile phone app. Anyone with the right access details could write a mobile phone app to use cell tower information, built-in GPS, or any other cues, to update location as the user moves around. This is the no-brainer example of an automatic mobile updater.
  • Twitter. When you tweet with “L: london”, a twitter monitor app could notice that and notify FireEagle. (As with all cases below, you must have authorised the monitor app to do that.) This example illustrates that users aren’t always passive lemmings walking around with a mobile updater app in their pocket. It may be that location data is only ever updated when a user proactively tweets their location.
  • A client that watches you adding geotagged photos to Flickr, and assumes you are in the last location you uploaded.
  • Specialised tracker device. Devices based on GPS (e.g. SPOT) could easily be made to update FireEagle with their location.
  • Car app. Based on GPS, a car’s location could be tracked using FireEagle. (The car, not the driver.)
  • Travel card. (My example.) Theoretically, your travel card could update FireEagle location as you move around. Same for transponder devices in cars.
  • Many, many, more examples.

What kind of clients act as location consumers?

  • Find nearby friends, tourist attractions, pubs, etc.
  • Find currency rate (since you know what country they’re in)
  • Phrases in the local lingo or an online dictionary
  • Location based games
  • Many, many, more examples

Some clients may act as both updater and consumer.

Privacy

The other thing FireEagle gets right is great concern for privacy – users can give out as much or as little data as they like, and they can stop the service at any time. The first way this happens is with OAuth, which lets you manage which services can perform what actions. You can start and stop this at any time. In the future, there will be a simple client to let you log in from your mobile and control all this. In particular, you will probably be able to suspend all tracking at any time.

Additionally, you can apparently set granularity, so you could expose just a general area, e.g. whiiich city or country you’re in, instead of a particular co-ordinate.

In the future, you will probably be able to authorise a client just for a certain time, e.g. during a conference, after which it can no longer access your data.

At some point, historical data may become available. The team said if this happens, they will allow users to delete and edit their past data.

In summary, the team has been very careful to ensure users have complete control over their own data,

Very Raw Notes from Presentation

Tom Coates is talking about FireEagle.

FireEagle is the old CS classic: a layer of intermediation – between location identification systems and location consumer systems. As a user, I can tell FireEagle where I am and any permissioned app can make use of that data.

London is about the most frequent location for fireeagle

What would your existing/past apps look like if they had location services available?

e.g. Navizon

e.g. ZoneTag

e.g. Firebot – Make it your twitter friend and direct message your location to it.

e.g. BrightKite – cf dodgeball

e.g. Rummble

e.g. Plazes – determines your location via wifi. Then shows where you are on map, people around you, etc etc. And updates FireEagle

WikiNear – ~1M geo-tagged articles in wikipedia. Wikinear exploits that data – as you’re walking around, shows you the closest POIs that are in wikipedia.

Lightpole

Outside.In

Fireball – where your friends are

Fire Widgets – weather where you are, nearby Flickr photos

Moveable Type

Facebook “friends on fire” app – shows where your friends are and updates your Facebook status

Could be great…

Spot – specialised comms/phone device for backpackers, aid workers, etc. ~100pound for device, 100pound a year and keeps updating your location every� ten minutes. Doesn’t integrate yet but great example if it did

Ambient Orb – e.g. changes colour as you move away

Nabaztag

Geotagging all user generated content – cinema listings, local traffic, local TV stations, nearby friends, weather forecast, local exchange rates, public holidays, windspeed. A lot of this is on wikipedia thanks to geotagging.

Friends and family widgets. e.g. where they are in the world, what time it is, weather, etc. (A gadget for each person.)

Last.FM – On cracked iphone, can get mobile scrobbler on iphone. What if it recorded where you were, then you could see which songs people play in particular areas. Cool!

Pacmanhattan – Lots and lots of game ideas (idea: scavenger hunt! reminds me of geocaching)

(later mention: geocoding animals, e.g. track migration)


Later on, expecting it to track historical data. (and since it will be user-modifiable which means you could back-track your entire life! (or someone elses eg fake shaekspeare))

http://tinyurl.com/5gtj92

http://tinyurl.com/3uklhl


Building an APP

(http://fireeagle.yahoo.net/developer/documentation/getting_started)

1 – Get API key 2 – User authorises your app 3 – Make API calls to Fire Eagle Outside.In -�

Who’s within an area

Each consumer key and secret identifies an application using Fire Eagle.

User Authorises ….

There are three models and the difference is purely to do with differences in (app triggering web page) and (web page triggering app). Web: Can trigger in both directions Mobile: Can’t trigger in either direction (maybe, but can’t assume it) Desktop: App can trigger web page, web page can’t trigger app

Web App model: Request token

I asked which model was used for widgets. Answer: Desktop. (Makes sense, with current technology. Web model would cause redirection from container. Later on, Opensocial will have oauth built in.)

Core Concepts

Note: social graph (user and friends) is beyond scope

location – point or bounding box location hierarchy – set of locations

Exposed RESTfully:

  • user() – duh
  • lookup() – provide location string and choose from list of resolutions (which “london”??)
  • update() – duh. call it and it “moves you”
  • within() – ?
  • recent() – “map of soho and everyone in there” OR “last 100 updates from my users”

walking through http://github.com/mojodna/fireeagle-tutorial/tree/master/ruby

Will probably support xmpp/Jabber too – more appropriate than HTTP for this

OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing

OAuth, OpenID…they sound like the same thing and they kind of do vaguely similar things But I’m here to tell you, OAuth is not Open ID. They have a different purpose. I’ve been playing around with OAuth a bit in the past couple weeks and have a grip on what it’s aiming to do and what it’s not aiming to do.

To start with, here’s what OAuth does have in common with Open ID:

  • They both live in the general domain of security, identity, and authorisation
  • They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance. Think REST, not SOAP. Think Bar Camp, not The 25th Monosemiannual International Convention for the Society of Professionals who Devise Acronyms Quite a Bit.
  • They both celebrate decentralisation. There is no central Open ID or OAuth server that holds all the security information in the universe (cf Passport). Anyone can set up as a server or a client.
  • They both involve browser redirects from the website you’re trying to use – the “consumer” website – to a distinct “provider” website, and back again. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.
  • The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.

With that much in common, the casual observer could be forgiven for confusing them. But they’re different. Not different as in “vying to be the no. 1 standard”, but different as in “they let you do different things”. How so?

Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr. OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.

With OAuth, you still need to log into the provider. e.g. When Moo sends you to Flickr, you still have to log into Flickr (or be logged in already). How Flickr decides you’re logged in is completely orthogonal to OAuth. It could be a standard username-password login, it could be via a physical password device, or it could well be via Open ID.

With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you, e.g. some photos, addresses, phone numbers, etc., and with your consent, send it back to the consumer so you don’t have to re-enter all the boring profile details again. However, this is data of a generic, non-application-specific, nature. (And even this limited form of sharing is an extension to the core Open ID spec.) With OAuth, any information you hold on any website can be shared with another website. You could share your GMail with a clever consumer that automatically tags items by inspecting the content, if GMail was an OpenAuth consumer.

Or you could copy your GMail address book into Facebook, by allowing Facebook to read your GMail account. Right now, the only way to do that is to give Facebook your GMail username and password. Clearly a dumb thing to do, and that’s exactly the kind of thing OAuth is set up to prevent. OAuth prevents it by explicitly asking you if you want to let Facebook grab your details from the provider. That’s not a problem Open ID solves. Even if Facebook and GMail used Open ID and you had accounts with both against the same Open ID, you still couldn’t get Facebook to read your GMail account. The Open ID provider wouldn’t let Facebook log in to GMail as if it was you. Even if an Open ID extension came along to allow it, you wouldn’t want it. It’s too coarse-grained and would allow the consumer to do too much potential damage. OAuth is more fine-grained – consumers can do some things with your provider data, not everything.

Advice to OAuth Providers: Consumers, Consumers, Consumers

Gabe Wacho offers some good advice to OAuth providers:

Understand that many of the consumer applications of your service are driving users to your site, and in the world of composable services, your consumer application developers will often have choice. Choice means power. Recognize.

Several good points in his article. The main message, though, is to target consumers, not just end-users. This is sound logic, like a chocolate manufacturer seeing its retailers as a customer, as much as the guy who eats the chocolate. Stated in strategic marketing terms, Porter’s Value Chain reminds higher-level suppliers to see through the eyes of those they supply to, so they can understand how they add value further down the chain. e.g. our chocolate manufacturer considers how it can help a supermarket add value to the chocolate bar, e.g. by its product design, packaging, reporting systems, delivery mechanisms.

In the software world, one company which heavily relied on this principle is Microsoft. As mentioned in The Story Behind “Developers, Developers, Developers!!!!”, MS traditionally focused heavily on developers to make the platform flourish. On the whole, companies on the web are pretty good at this nowadays, with developer blogs and the general use of Documentation as Conversation.