Today was a busy day of launching stuff in Google+ land, and it is pretty easy to miss out on one or two features - particularly as the rest of Google wasn’t exactly keeping quiet on that front either. I wanted to briefly review what has happened, and why its interesting.
Incremental Auth
One problem if you’re integrating multiple Google services is that you have to ask for a laundry list of scopes. This new release means that if a user has already granted you some scopes, when you ask for more they will only see the consent screen for the additional one(s). You can check this out on 8tracks right now on the web when you connect your YouTube profile after sign-in, but it’ll work cross-platform.
To use it on Android or iOS just reauthorise with the additional scope. On Android you’ll need to add the scope and reconnect the PlusClient:
On iOS, add the scope and call authenticate again.
In both cases, its best to track which scopes you have, so you know whether you’re going to prompt the user. The web, however, makes this a bit easier! There is a new parameter includegrantedscopes which will automatically add previously granted scopes to a token, so you just have to request the ones you want. This is definitely best used with the page level config. You can have the basic scopes defined there, and the additional requested via a gapi.auth.signIn call:
Ability to migrate from OpenID2 to Google+ Sign-In/OAuth 2.0
Up until now, developers that were using OpenID2 had no easy way to move to OAuth 2.0/OpenID Connect. This has been resolved, thanks to the addition of an open_id parameter in the ID token. This allows you to look up an existing OpenID user and associate them with the Google+ user ID.
This requires specifying the openidrealm parameter on the sign-in button, with the realm you are currently using for OpenID. Then, grab the ID token from the sign-in callback and send it to a server that can check the mapping by looking at the open_id parameter and the sub parameter for the regular Google+ ID.
Simplified sign-in scopes
Similarly, things were a bit complicated if you wanted to use Google+ Sign-In, but had users that didn’t have Google+ profiles. Two things have improved that:
- You can now use the scope profile (that’s just profile, no https://www.googleapis…) with the sign-in button, and request only basic profile information. This will work for users who have not yet upgraded to Google+, and won’t push them through the upgrade flow.
- If you have enterprise users who have Google+ disabled, they will additionally be able to log in with the https://www.googleapis.com/auth/plus.login scope. Of course, API calls for things like friends will fail, so you should watch out for 403 errors.
There’s more about this and the OpenID updates in the auth migration documentation.
Upgraded plus/people/me
Another pain point was having to call a different API to get the user’s email address, or for a non-Google+ users’ profile. No longer! The plus.people.get endpoint will now work for users who have not upgraded to Google+ (with the profile scope), and it will also include email addresses. You still have to request permission to read the email address, but you can use the shorter email scope (again, no https://www.goo.. prefix), or the new https://www.googleapis.com/auth/plus.profile.emails.read scope.
Both of these will return the account email address in the emails field of the response. However, this field is an array, in the plus.profile.emails.read case any other verified emails associated with the account will be returned, which can be handy for matching users against existing app accounts. The first email returned (of the account type) will always be the primary email.
{
"kind": "plus#person",
"etag": "\"z42GAODeSfK9shwebqCuJQuYEu0/ZPDmtuV2cBdoJq7ydemTXzboBfk\"",
"emails": [
{
"value": "email@address.com",
"type": "account"
}
]
...
people/me/people/connected
Another long-standing API request is the ability to not just get back a list of who the user has in circles, but also which of those users have used your app. This is accomplished with the new connected collection on people.list.
GET https://www.googleapis.com/plus/v1/people/me/people/connected
{
"kind": "plus#peopleFeed",
"etag": "\"z42GAODeSfK9shwebqCuJQuYEu0/X-wx7Kx1_yYxA7zSOPxnVdHh_qA\"",
"title": "Google+ List of Connected People",
"totalItems": 4,
"items": [
{
"kind": "plus#person",
"etag": "\"z42GAODeSfK9shwebqCuJQuYEu0/HLHQbLg-DN9PK6BJ5oFljAa71Uw\"",
"objectType": "person",
"id": "118051310819094153327",
"displayName": "Chirag Shah",
"url": "https://plus.google.com/+chirags",
"image": {
"url": "https://lh5.googleusercontent.com/-XnZDEo..."
}
},
...
While you could have tracked this sort of thing by hand before, this makes it a lot easier and less resource intensive.
Resource timing in the Google+ widgets
The first step to improve performance is generally to get good measurements. The W3C Resource Timing spec defines a standard interface to expose timing measurements, so that its easier to track the different stages of execution of chunks of Javascript. As of today, the Google+ plugins (and others!) support this interface, so you can see how much time they take to load.
That’s the lot for today! I’ve probably missed something as well, so feel free to comment if you can think of anything else, and watch out for more releases before the end of the year.