Logging in with Google, Microsoft and Facebook SDKs to Azure Mobile Services

One of the values that Azure Mobile Services provides is an easy way to implement authentication for mobile applications, via a very simple API – call a login function (or equivalent) on the client object in any of the supported platforms, and your user gets presented with a simple web-based interface that allows them to log in to your mobile service. This is what we call a server-side authentication flow, where the service guides the client to the provider (via redirections in the web page) and then back to itself. Using a server-side authentication is a good way to start an application, but if the authentication provider which you want to use has some native SDK that supports login, then your user would have a better experience if your app used it. For example, if your user is in an android device, it’s very likely that they have a Google account associated with their device, so if they can use that account without having to re-enter their credentials, that makes for a better user experience. Same thing with a Facebook account in an Android, iOS or Windows Phone device, or a Microsoft account on a Windows or Windows Phone. This scenario is what we call a client-side authentication flow, where the client application talks directly to the provider (via its native SDK) and then just exchanges some token from the provider with the mobile service to authenticate with the service itself. We’ve had the client-side authentication flow working for Facebook and Microsoft authentication in the node.js backend for some time, but not in the .NET runtime. We also didn’t support Google SDK authentication in any of the runtimes – until now. We just released support for Google authentication in the node.js backend, in addition to supporting authentication via data from SDK from all those three social providers in the .NET SDK. This hasbeen a long-requestedfeature that we’re glad to see live. In this post I’ll walk through how to use this new feature.

Microsoft Accounts

Logging in to Windows Phone / Windows Store apps from the Live SDK has been an option to node.js backend since the first release of mobile services (in node.js). Now that it’s enabled in the .NET backend, the steps to enable it are exactly the same as in node: register the app for authentication and copy the Windows Store dashboard information to the mobile service’s identity tab, add Live SDK to the application; login using the Live SDK and later send the authentication token received from the SDK to the mobile service. All those steps are listed in the tutorial at https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-single-sign-on/ and you can follow them to add the Live SDK login to your application which uses the .NET backend.

Facebook Login

Similarly to the case with Microsoft account, logging in with tokens from the Facebook SDK has been an option in the node.js backend for a long time. The .NET backend now also supports this client flow. Also, like in the previous section, there’s absolutely no difference in the client code (or even in the code in the server that you have to write), so all the tutorials for node apply to the .NET backend as well. You can find more information about adding login via Facebook SDK to your apps in the following blog posts: iOS Apps and Android Apps.

Google Login

The client authentication flow for Google accounts is a new feature for both the node.js and the .NET backend, and it works the same for both. Let’s go through the scenario of adding a login operation to an Android app.

Integrate Google+ into your Android app

To add the Google sign-in to your application you need to add the Google Play Services library to your application. The getting started page in the Google documentation has all the steps required to do so. Notice that in first step, where it tells you to create a new project in the Google Developers Console, instead of doing that you’ll be using the same project which you created in the previous step. In your project you’ll already have a client ID for web application, and you’ll be adding a new OAuth client ID for an Android Installed application.

Adding Sign-in for your Android app

Once Google Play is properly set up for your project, we can now start using it to log in, first to Google itself, then to the mobile services. Before using the Google Play Services, we should always check whether it exists (it can save you a lot of time debugging in case your emulator isn’t properly setup, as it happened to me before).

Once we’ve established that the service is running in the device (real or virtual), then we can choose the account which is associated with the device that the user wants to use. For that we’ll use the AccountPicker class, which will show a UI for the user to select their account, or if the user has only one account, then it will automatically choose it without needing for user intervention (a better experience).

Since the picker UI is presented as a separate activity, we need to override the onActivityResult method to get the result. In the result we can get the name of the account that the user wants to use, and once that’s done, we can request the token that is necessary to log in to the mobile service.

The token which we need from Google to login to the service is an ID Token. An Android ID token is used to authenticate the user to a web application so that Android apps can talk to the remote service without requiring the user to log in again. This is a form of cross-client authentication, in which the user authenticates with the native app defined in the developers console, and then presents the token to the remote app (the mobile service), which in turns validates with Google that the token comes from the same project. Remember that we created two OAuth client IDs associated with the same project? That’s how the mobile service and Google can communicate to ensure that the user is authenticated for that application only. To retrieve the id token the device needs to be online (another good practice) and then go to a background thread to retrieve the token – for which we’ll be using an AsyncTask.

When we validate that the device is online, we can use the GoogleAuthUtil.getToken method that takes the account we want to use and the scope of the request. For cross-client authentication, the scope is defined as the prefix “audience:server:client_id:” followed by the client id for web application (which was created in the first step for this section) – do not use the client id for Android application in this case. If the user has yet to authorize the application to use their data, then a UserRecoverableAuthException is thrown, and we can deal with it as we’ll show later. If the user has authorized the app use their information, then a token will be returned, and we can take that token and send to the mobile service’s login call, by wrapping it in an object with a property called “id_token”. Once that call is done, we’re logged in to the mobile service and can access protected resources.

The last piece of the puzzle is to handle the case where the getToken method returned a recoverable exception. In this case, we can handle the exception by starting the activity given to us by the exception, which will show the dialog prompting the user to authorize the app to be used. We need to then update the onActivityResult implementation so that when the app returns from that authorization screen, it can make the call to get the token again (and, if the user has authorized the app, it will succeed).

And with that we’ve shown how you can add native Google authentication to your mobile app and use it to log in to the mobile service. As I mentioned before, this works the same way for both the node.js and the .NET backends.

Wrapping up

It’s always good when we’re able to release a feature that have been requested for a while and this week we did that. Hopefully this will help Azure Mobile Services add more value to your applications, by giving your users a better user login experience. As usual, please send us feedback either as comments in this post, via twitter @AzureMobile or in our MSDN forums.