Risk Complete Failure

The new Google Sign In SDK for iOS is out! With a new version number, and separated from the old Google+ SDK, the Sign-In SDK should make it easier and faster to implement Google Sign-In in your app. Lets take a look at how to use it from Swift.Unfortunately the library isn't available from Cocoapods yet, so you'll have to drop it in manually. Setup is pretty easy: add in the GoogleSignIn.framework from the zip download and add the system AddressBook and SystemConfiguration frameworks. If you want to use the supplied button, you'll also need to add the GoogleSignIn.bundle from the SDK zip which contains the fonts, images and translations for the standard button - using the Add Files to "project" menu option should automatically set it in the Copy Bundle Resources part of your build step.If your sign in button is invisible when you launch the app, you probably haven't copied the GoogleSignIn.bundle from the SDK zip file.In the Build Settings phase, add -ObjC i…

Misconceptions about Google service accounts are at the heart of a number of problems I’ve seen developers having on Stack Overflow and various issue trackers. Hopefully this post will dispel some common misunderstandings, and break down what they are for. What is a service account for?Requests to many APIs need to be authorised to access data or services. In most cases this is done interactively with a user - the site presents a sign-in button, the user grants the site access to a part of their Google account, and the site receives an access token they can pass with their requests. Google checks this token to ensure the query is allowed to access the data it is requesting.However, there are some situations where the user is not actually present - for example a daily batch script which downloads data from a Google Analytics account, or a process which provisions services for a Google Apps user when a new staff member starts at a company. In these cases, a service account is used to r…

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?Check whether you're using userinfoUpdate scopesReplace userinfo API call with a call to plus.people.getAre 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 …

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…

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 problemSeveral 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. The only rea…

At my talk at Over The Air 2013 this weekend in the wonderful Bletchley Park, one thing that surprised some people was the fact that Google has a OAuth 2.0 option for low capability devices. This is one of the big benefits of using Google as an IDP - it allows you to take advantage off all the work that the identity and security teams do in areas like 2-factor auth, data management, and access for all sorts of different environments.The devices setup is really for cases where you want to allow a user to sign in to something that doesn't have a great control setup - for example a TV or a wifi-enabled toaster. With it, the user only needs to indicate that they want to sign in, but they actually authenticate in a web browser on a regular PC or their mobile device. You can take a look at how it works below. This iframe is representing a device that you might want to sign in to, and as soon as you click the Sign In button below, it'll try to sign in and give you a code. You'll …

Recently I've been in a couple of conversations where the idea of testing whether a user is logged in to Google came up. This can be helpful for tuning the experience when presenting sign-in options: you can highlight the Google+ Sign-In button on the basis the user was already signed-in to Google, so should just need to consent. It's also one way of responding to the fact that signed-in users typically are going across search using HTTPS, so you don't get information about the search terms a user used to reach you. By highlighting the benefits of signing in, the users may choose to do that, and hence give much more ability to personalise and so onThe (slightly arcane) method for doing this is checkSessionState. This is a bit of Google oAuth 2.0 plumbing that allows cheaply checking whether things have changed without round-tripping to the server in many cases. There is a session state, which is kind of a hash of various aspects of the user's signed in status, locally …

As part of the release of Google+ Sign-In, some people have noticed that signing in via the Sign In button doesn't redirect them to Google, then back to the site, as would have happened if they'd been using the basic OAuth 2.0 flows.

One of the backbones of Javascript security is the same-origin policy, which limits running code from being able to see things from sources other than its own. For example, HappyImageWebsite.com can't go and read what's happening on another window showing SecureBank.com. Sometimes though it is helpful to be able to communicate between windows, or between a window and an iframe, that are from different origins. This is tricky, and has been the source of many interesting workarounds over the years.

The HTML 5 web message specification standardised a solution to this problem, in the form of the window.postMessage() method. As you might guess, this lets you send a message from one window to another in a pretty straightforward way, even if the…