Google Sign In with Server Side Auth on iOS

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 part varies. If you try and exchange a code generated for one client ID using a different client ID you'll get an invalid_client error, even if both client IDs are part of the same project. When the user is signed in via [GPPSignIn authenticate] you can retrieve the code parameter from the GPPSignIn instance as part of the auth callback:

You can send this parameter to your server exactly as you would with one from Javascript or Android. When exchanging, be sure to not set a redirect uri in the server side auth configuration or you will get back a HTTP 400 error "redirect_uri_mismatch" from the token POST call. The exchange should always result in a refresh token (unlike with the web), so be sure to store that safely in a database or other persistent store if you're using it.

If the user is seamlessly signed in via a call to trySilentAuthentication, you won’t receive a code to use. Instead of forcing the user to sign in again with authenticate (and swap out to the browser or Google+ app to consent again) when you’re establishing a session with the server, try sending across an ID token and checking whether the server already has a refresh token for that user - this will mean a smoother experience for the user in most cases.

Popular posts from this blog

Common problems with Google+ Sign-In on Android

Image
It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps  and other events I've had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services , but there are still some issues I've seem come up a couple of times. tl;dr: make sure your app is set up in the API console, and make sure you can handle multiple onStart events coming in during sign-in. 1. Consent screen appears more than once.  The basic life cycle of the PlusClient looks a bit like this: When we call the onStart, we immediately call mPlusClient.connect(). Google Play Services checks whether the user is already signed in to the application, and, if so the onConnected method is instantly called and the user seamlessly signed in. If the connect() call fails, then onConnectionFailed() is called with a ConnectionResult object, which represents the error. The error is

Client-Server Authentication with ID tokens

Image
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 Tokens This whole architecture relies on a point of view which I suspect is still not particularly common amongst developers impleme

Are you using approval_prompt=force?

Image
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.