Migrating to Google+ Sign-in in 5 minutes

Are you looking to understand the available strategies for migrating your existing Google login solution to Google+ Sign-in? Well… You’ve certainly come to the right place

If you're using OpenID1, OpenID2, OAuth1 or OAuth2Login then we have a detailed migration guide: https://developers.google.com/+/api/auth-migration

I strongly recommend reading it. Or at least skimming it since the social login market is bigger and more complicated than it seems. The following is merely a high-level restatement of the migration guide for people who aren't really sure which of the aforementioned technologies they're using.

If your existing system captures the user's email address using a Google identity solution then you can just:

• migrate to Google+ sign-in
• ask for the email OAuth scope
• fetch the user's email address using one of our recommended approaches
• look up the user in your database by email
• associate them with the existing record that matches that email address since Google guarantees that the email addresses are valid

If your existing system doesn't capture the user's email address then life gets interesting.

If you're sure you're using OAuth1+OpenID2 then you can follow the instructions here: https://developers.google.com/+/api/auth-migration#oid2 which tell you how to fetch your old identifier and find out the equivalent identifier with Google+ Sign. Once that's done you can just associate the new identifier with the existing record and the user can sign-in in future with Google+ Sign-in.

If you're using something else then you can ask the user to sign-in twice: firstly with your existing Google identity solution then with Google+ Sign-in. Now that you have both identities you can associate them in your database. Once a critical mass of your users have gone through this process then you can stop using the legacy identity solution. If you have to use this option then I would also recommend reading Michael Mahemoff's experience report from Player.fm's migration: http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus since I got the idea from him.

Minimum-viable identity provider

What's required in a minimum-viable IDP (Identity Provider) in 2013?

When I talk about viability I really mean "competitiveness" and I suppose what I'm really asking is what does it take to get RPs (Relying Parties) to integrate and users to authenticate with an IDP?

The list of requirements below was first published in a presentation I gave at Over The Air 2013. It's the result of hundreds of conversations with RPs and user over the last few years.


Valuable accounts. Are the accounts attached to real people who have been SMS verified? Does the IDP fight off attempts to create fake and spammy accounts?

Security. Are the accounts stored using salting and hashing? Do users authenticate using multiple factors? Are precautions being taken to ensure that user accounts are protected?

Rich profiles. Does the IDP offer data that you can use to personalise your service such as profile data, photos and social/interest graphs?

Ubiquitous APIs. Does the IDP offer ReSTful APIs, native SDKs, client libraries in various languages and support for RTL languages?

Escape hatches. Does the IDP lock-in RPs and/or users? Can the RP obtain the user's verified email address so that the user has the option of using a different IDP with the same RP account? Is the RP forced to build their own post-registration flow?

Business model. Does the IDP make money or otherwise benefit from providing this service? Do they have a compelling incentive to stay in this business?

The final and most controversial ingredient is scale. Most people would say that all other things being equal an IDP with more accounts is better than an IDP with fewer accounts. I'd suggest that it's better to have accounts that are appropriate to the service the RP is trying to provide. For instance for Statigram the best IDP is Instagram but for Favstar.fm the best IDP is Twitter and, of course, for any service that uses Google services (like Youtube, Android, Drive, etc) the best IDP is Google+.

The items listed above are just the necessary but not sufficient features of a viable IDP. Successful IDPs will still have to identify and provide additional value in order to get widespread adoption by users and RPs.

Beyond the NASCAR

People in the identity world worry a lot about the NASCAR problem. 

They worry that showing a large set of buttons will hurt conversion rates (because of the paradox of choice) and confuse users who don't remember which IDP (identity provider) they used on a particular site+device combination. 

I don't think that's a big problem nowadays. 

That's because we're down to a fairly small set of viable identity providers (henceforth known as IDPs). Most of the others are either dead(MyOpenId), new (Amazon Login) or only useful in specific niches (GitHub, Instagram, Tumblr, LinkedIn etc).

If we look at Stack Overflow's data we see that 5 IDPs are used by 98.6% of visitors but everybody has to deal with the cognitive load of choosing between the 12 buttons and 1 form field. 

Reducing the set of buttons to 3 would still give users a choice whilst reducing cognitive load. By cutting down to just these 3 IDPs they'd have covered the vast majority (in Stack Overflow's case 92.02%) of potential users of their site and greatly simplified the experience. 

However if you prioritise providing access for 100% of your users over providing the best possible experience for the majority then you have several alternative strategies available to you:

• create your own username/password system (but then you have the responsibility of building a first-class security system)
• use AccountChooser
• build your own equivalent of AccountChooser or something equally clever
• use Mozilla Persona (although it has various issues that I'll probably write about in the future)

If your goal is optimising the percentage of users who sign-in and making sure those people get the best possible experience then here's what I suggest:

• Use Google+ and Facebook buttons (there are also going to be scenarios where Weibo/Renren/VKontakte are appropriate additions). 
• Then use checkSessionState() and FB.getLoginStatus() to find out if the user is already signed in to Google or Facebook. The mobile SDKs have equivalent APIs.
• Then suggest whichever account the user is already using by putting that button first and/or making it bigger. 

We've even published a guide to handling the scenario where the user is signed-in to both IDPs and you can automatically bypass the sign-in screen. 

However there's still the situation where a user prefers different IDPs on different machines: for instance if they work in a company that blocks Facebook at the firewall or they prefer Google+ on Android but Facebook on iOS. For those users a naive NASCAR implementation leaves them with one account on your service per IDP. 

The easiest solution to is to ask for the user's email address and use that to correlate all the accounts they use to login to your service. That way the user never has to worry about creating duplicate accounts. Of course this does restrict you to IDPs who can offer a verified email address. 

The only IDP this excludes is Twitter. If you are using Twitter as an IDP then you'll have to either capture (and verify) the user's email address in a post-registration step. 

Sometimes you have to do things the hard way. Usually it's because you have large numbers of accounts with unverified email addresses (for instance if you used a standard OpenID IDP or used Twitter without capturing and verifying email addresses) or you're migrating users from one IDP to another. 

In that case you have to provide a 'connect flow.' This is where the user signs-in to your service with one IDP and you ask them to 'connect' with additional IDPs. Afterwards you know that the same person owns that set of accounts even if they have different email addresses associated with them. 

The heuristics above mean that the NASCAR anti-pattern doesn't have to harm conversion rates or UX.

If you'd like to learn more about this stuff I'll be attending Over The Air 2013 where I'll be walking people through examples of these heuristics in production and talking about the multi-device multi-platform post-NASCAR future of identity. Join me. 

A world of social login

We've known for years that passwords are bad.

They're bad for users because they tend to use the same weak password across multiple sites which means they're only as safe as the least secure site they use. They're bad for developers because the sign-up process loses a large portion of potential users. They also force every developer to jump through all the steps required for a world-class identity system:

• multi-factor authentication
• the forgot password dance
• a salted and hashed password database
• etc.

Despite all this, passwords and the password anti-pattern are still prevalent.

Social login isn't a panacea but in the long run the only viable solution is delegating authentication to a small set of high quality identity providers. It has to be a small set to avoid the damage to conversion rates caused by the NASCAR problem. They will be high quality since the market is so competitive that low quality providers (where quality is a measure of the experience/value provided to users, developers and publishers) will find it hard to acquire and retain users. The market will be competitive simply because various entities have realised that social login is the backbone of any successful ecosystem so they're making the necessary investments.

This is sub-optimal but the OpenId dream (where every user runs their own server and their own OpenID endpoint) ran aground on the twin rocks of user apathy and security. Even if the dream had survived that it still didn't have a good answer to the major publishers who wanted to know what they would be getting in return for the extra effort of supporting OpenID. If you think OpenID Attribute Exchange and PAPE are solutions then you may be wearing the complicator's gloves.

The only questions left are:

• who will be these identity providers
• what will be their business models
• how will we assess and choose between them
• how will we keep them honest
• how much control do they give users
• do they help developers build better and more valuable services as time passes
• will they become gatekeepers that constrain future innovations

This moves us to a world where users authorise developers rather than particular apps or web sites. As a result once you give a developer access to your information you give all of their services and apps access to your information. Technologies like OAuth2's bearer tokens mean that developers can easily pass access to a user's information back and forth between their mobile apps and their back-end systems.

In this new world developers will have to deal with multiple competing identity providers who each impose their own constraints and policies in order to protect their users. As a result developers will have to start thinking in a more sophisticated way about the way they propagate identity between their different systems, track the provenance of user data and honour the conflicting policies imposed by multiple identity providers. They'll also need more nuanced terminology. It won't be enough to think solely in such crude terms as "public" versus "private". Developers will also have to be aware of the subtle distinctions between "obscure" versus "secret" and "public" versus "publicised".

In return we get a world of social login where you bring your identity, your interests and your community to every app, service and device rather than just the ones built by identity providers with unified privacy policies.