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 account…

YouTube is an amazing resource for creating and discovering videos, but it is valuable for people building non-video experiences as well. Looking at YouTube usage is a great way of finding out what a user is into, and can help provide information to allow a more tailored out of the box experience. It's really easy to request access to YouTube alongside Google+ Sign-In, and then use the YouTube API to retrieve the user's watch history or their likes.YouTube offers several scopes for allowing access to different facets of the functionality, but in this case we will be using the readonly scope. This means the user only consents for the application to view their activity on YouTube, and doesn't grant it the ability to upload videos or subscribe them to channels. In an Android setup, we can request the scope with our call to PlusClient.Builder. Because the YouTube API is not part of Google Play services, we will also need to create a GoogleAccountCredential from the Google Java…

Social sign-in adds an extra twist to sign-in on the web. While systems like OpenID are often used purely to assert identity (e.g. you are the same person as when you came here before), OAuth and OAuth 2.0 were always about granting access to data (e.g. you give me permission to know who your name and friends). While both of these get to the same place for most developers - someone can log in, and you can reliably and securely know which user in an application they map to - the difference is largely about what other data is available.Most social sign-in systems grant access to profile information, such as name, gender, email address, age or age range, and other more specific information. They often also grant access to a users activities on the identity provider, either explicitly or implicitly: for example if I sign in with Google+ you can retrieve a list of the people I have circled (or at least the ones I have given you access to), or if I sign in with Twitter you can easily get a …