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…

The release today of version 1.7 of the Google+ iOS SDK added the ability to authorise both a client and server for access to Google APIs. This has been a feature for Android and Web based sign-ins for a while, and now is available across all three platforms. This should simplify server side code for people who have been building cross platform apps - for example if you need to retrieve profile information on the client, but retrieve circles on a server for a friend finding feature.The implementation for iOS is fairly straightforward. When setting up authentication, simply specify the client ID of your server on on the GPPSignIn object. This should be a client ID from the developer console which is used by your server-side code, and should be part of the same console project as your iOS client ID. For those that have done it, this is the same parameter used when retrieving an ID token:You can see that the first part of the client ID (the project number) is the same, but the other par…

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 …

With all the changes to Google+ Sign-In at the end of last year, it was easy to miss some of the extended options that have been added. In particular, this update added "profile" as a valid Google+ Sign-In scope, and its not immediately obvious what the implications of choosing between the different sign-in scopes are.To help give a bit of context to the problem, there are really only three states of users that need to be considered when choosing a scope:Google+ user: This is a Google or Google Apps user who has a Google+ profile. Non-Google+ user: This is a Google or Google Apps user that has not upgraded to Google+.Google+ disabled Apps user: This is a user of a Google Apps account where the administrator has disabled Google+. We can take a look at the two main sign-in scopes with that in mind.profileThe most basic sign-in scope is profile. This can be used for all three classes of users. A token will be returned through the normal OAuth 2.0 process, and you will be able t…

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…

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 TokensThis whole architecture relies on a point of view which I suspect is still not particularly common amongst developers implementing au…

One of the questions that you face as a developer when implementing Google+ Sign-In (or any login method) is how to present the options to the user. Having reviewed a pretty large number of apps with sign-in, I thought it might be helpful to break down the four main approaches for displaying the buttons that I've seen, and some thoughts on the costs and benefits of them. A couple of points before we get into that: It's worth remembering that the best situation is when the user does not have to take any action at all. That's the idea behind cross platform single sign on and over-the-air installs. It's also why it is worth taking the time to make sure users stay signed-in after an app upgrade or releasing a new version of a website.Secondly, unless there are solid reasons not to, sign-in should always be paired with sign-up. Particularly on mobile devices this can be a missed opportunity where users are expected register on the web first. That said, in this post I want t…

NOTE: This blog post is pretty old! Take a look at a much better way of getting an authorization token or check out the official Google Sign In documentation for a more up to date (and easier!) choice.Google+ Sign-In is a really easy way to authenticate and identify a user and build interesting experiences on Android. Some apps needs more than just an authenticated Android client though - they also need to make Google API calls from their server, perhaps even when the client is offline. Enabling both to access the APIs at the same time is slightly tricky, but in this post I'm going to try and break down what is required, and how you can do this in a robust and reliable fashion. Note that life is much easier if you just need either the client or the server to have API access, or just need to identify the user to a server. This approach is solely for the case where you make Google API calls on the Android client, and also Google API calls from the server.Our model is that we have an…

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 …