Migrating Away From Userinfo

As part of the move to full OpenID connect support recently, the "userinfo" scopes and endpoint were deprecated and scheduled for shutdown in September 2014. If you are using the userinfo API endpoint to retrieve email address or profile information for a Google user, now is the time to change! Luckily, it's just a few minutes of work to move from the userinfo API to the people.get API for most people, and wont affect users at all.

What should you do?

  1. Check whether you're using userinfo
  2. Update scopes
  3. Replace userinfo API call with a call to plus.people.get

Are you using the endpoint?

Look for the section in your code where you retrieve the user's profile or email address. If you make the API call directly, you may see a URL like "https://www.googleapis.com/oauth2/v1/userinfo". The "v1" might also be "v2" as there are a couple of different versions of the api, but if it has /oauth2 then you're using the userinfo endpoint. If you're using a client library, look for using the (somewhat confusingly named) OAuth2 service or API. For example:

PHP: new Google_Service_Oauth2($client);
Python: service = build('oauth2', 'v2', http=http)
Java: oauth2 = new Oauth2.Builder(httpTransport, JSON_FACTORY, credential).build();

All of these are indicative of retrieving the user data from the userinfo API, and will need to be changed before September 2014.

What scopes should you use?

https://www.googleapis.com/auth/userinfo.profile and https://www.googleapis.com/auth/userinfo.email can be seamlessly replaced with the shorter strings profile and email. These are aliases, so they wont require the user to reconsent if they've already give access. If you're thinking about a larger change, check out my earlier post about choosing a sign in scope.

What API should you call?

All profile information for Google users is now served from the people.get API. This works for users whether or not they have a Google+ profile. It returns data in a slightly different format to the userinfo API, so you may have to change your code a little, but all the same data is available. A call to retrieve the users name, picture and email address would look like this in PHP (and should be analogous with any of the client libraries).

You can actually try the call direct from the "Try It" section at the bottom of the API page to see what the returned data looks like.

What if you want to make the smallest code change possible?

If you aren't using a client library, and don't want to change the parsing you're using, you can call the special getOpenIdConnect method, which returns data in the same format as userinfo. The only difference needed then is looking for the "sub" field rather than "id" (this was a spec change made during the development of OpenID Connect). Take a look at the differences between the calls to the API below

Userinfo API response

https://www.googleapis.com/oauth2/v1/userinfo?access_token=ya29.1.AA...
{
 "id": "104824858261236811362",
 "email": "ian@example.com",
 "verified_email": true,
 "name": "Ian Barber",
 "given_name": "Ian",
 "family_name": "Barber",
 "link": "https://plus.google.com/+IanBarber",
 "picture": "https://lh6.googleusercontent.com/-DXmOngLN6Gc/AAAAAAAAAAI/AAAAAAAAGc4/Roeci0EovY8/photo.jpg",
 "locale": "en-GB"
}
openIdConnect API response:
https://www.googleapis.com/plus/v1/people/me/openIdConnect?access_token=ya29.1.AA>...
{
 "kind": "plus#personOpenIdConnect",
 "sub": "104824858261236811362",
 "name": "Ian Barber",
 "given_name": "Ian",
 "family_name": "Barber",
 "profile": "https://plus.google.com/+IanBarber",
 "picture": "https:https://lh6.googleusercontent.com/-DXmOngLN6Gc/AAAAAAAAAAI/AAAAAAAAGc4/Roeci0EovY8/photo.jpg?sz=50",
 "email": "ian@example.com",
 "email_verified": "true",
 "locale": "en-GB"
}

In both cases, you do get a fair bit less than using the people.get API, so I would strongly recommend using people.get where possible!

There are a lot more tips on migrating to the newer sign-in options on the auth migration page, and of course if you have any questions drop into the StackOverflow tags for google-plus and google-oauth.

Popular posts from this blog

  • It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps  and other events I've had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services , but there are still some issues I've seem come up a couple of times. tl;dr: make sure your app is set up in the API console, and make sure you can handle multiple onStart events coming in during sign-in. 1. Consent screen appears more than once.  The basic life cycle of the PlusClient looks a bit like this: When we call the onStart, we immediately call mPlusClient.connect(). Google Play Services checks whether the user is already signed in to the application, and, if so the onConnected method is instantly called and the user seamlessly signed in. If the connect() call fails, then onConnectionFailed() is called with a ConnectionResult object, which represents the error. The error is
    Keep reading
  • These days there are few purely client-side applications - even traditionally unconnected software like casual games make use of servers and services to provide a better, richer experience - and importantly one that can follow the user across devices. We are in a world where we need to authenticate a user of many clients to a set of back-end services. There are a few ways of doing that when using a identity provider, like Google, but in this post I want to talk about a specific method that makes use of ID tokens. This approach has been well covered by Tim Bray for Android , but with the release a couple of months ago of the iOS 1.4.0 SDK for Google+, it is now available across Android, iOS and the Web. This makes it a particularly powerful way of signing in a user, and asserting the identity of that user securely to your application servers. Why ID Tokens This whole architecture relies on a point of view which I suspect is still not particularly common amongst developers impleme
    Keep reading
  • Version 4.2 of Google Play Services introduced a new replacement for PlusClient , GoogleApiClient . While PlusClient is still present, it will be removed in a future version so its a good idea to upgrade when possible. The new class has been designed based on feedback from developers across various Google Play services APIs, and provides a much more consistent, powerful base. PlusClient was reasonably straightforward for developers implementing just Google+ Sign-In. Unfortunately, anyone looking to combine multiple services together quickly realised that managing a series of callbacks for all the different connections was way too painful. GoogleApiClient solves that by providing one central client to connect or disconnect. It allows multiple APIs to be added to a connection for Google+, Drive, Games, and the other services available. Replacing PlusClient with GoogleApiClient isn’t too hard, and if you are using multiple clients makes life gets a lot easier - you don’t have to
    Keep reading