Risk Complete Failure

In my previous post I mentioned that there are two issues which have been made more visible by incremental auth. The first of these is fairly straightforward, but the second is a little more subtle. Incremental auth is a great feature for simplifying the consent screen that users see when they first sign in to an app, but it can also introduce a bit more complexity in some cases. An example of this is when requesting access to YouTube. Because YouTube profiles support delegated access to Google+ pages, their data can be associated with these pages as well as general Google accounts. Whenever you request access to a YouTube scope (even in combination with other scopes), the user will have the opportunity to choose one of their pages if they have any. Currently this only occurs on the web, and will result in the user seeing a screen like this: So far, so good - everything works as expected. Where it can get tricky is that if you ask for a YouTube scope incrementally, you need to a

The recent launch of incremental auth has highlighted a couple of problems in the way some sites have implemented Google+ Sign-In or Google OAuth 2.0. The most obvious of these is that there are a fair number of places that use approval_prompt=force much more often than they should, which leads to a much worse user experience than there needs to be. What’s the problem Several sites set approval_prompt to force either in the Javascript Google+ Sign-In button (where it is generally approvalprompt ), or in a parameter in the auth URL as part of a redirect based flow. This parameter means that users have to see the consent screen even if they had previously granted access to the application for the requested scopes. While this was never a great user experience, the recent release of incremental auth has made it even more visible. Because the user has granted access before, they are not shown most scopes. However, because force is specified, they have to be shown a consent dialog.

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 goi

At an event last week Ade , Lee and I hosted a discussion about cross-device sign-on, where we covered not only what it was, but why its interesting and how it works. One conclusion we came to was that minimising the number of times your users have to see the sign-in button and make an active choice to sign-in can really help smooth the experience of using an application. However, there are a couple of pitfalls that can mean you don’t feel the benefits from the feature. What do we mean by cross device sign-in? Once a third party is involved, authentication is no longer just about exchanging some credentials for a cookie or identifier of some kind. Unfortunately, a lot of the time we do exactly that: treat the sign-in as simply being a replacement for sending a username and password across to the server which can return a cookie. Once the user has a cookie, they are app-identified, and hence can use the site as normal. The problem is that this approach basically treats auth as a

During the development of the new Chromium powered Android WebView, Internet celebrity Matt Gaunt showed me some rather interesting demonstrations. This included integrating with Google Play services, in the form of letting the user natively sign-in from the WebView. Now all the changes are publicly available I had to try such a thing myself, and found it surprisingly straightforward! The first step is to actually create the HTML that we’ll be using. While it would be possible to use the Google+ Javascript SDK to make API calls and so on, I couldn’t actually think of a good reason to do so. What feels like a more general use case is presenting data retrieved through the API calls in the native SDK, which is how we’ll structure it. This is what my test page looks like, which is saved as part of my Android project in assets/index.html . Two things are of note here. First, we define a callback to be triggered after a sign-in. Second, we make two calls to MainActivity " one to