Windows Azure Mobile Services—Now We Are Getting Somewhere

The Windows Azure team just enabled a whole set of new features and functionalities for the still-in-preview Mobile Services offering. You can read ScottGu’s blog post with the full details (there is a lot), but I wanted to specifically highlight two huge features that are (IMHO) really going to drive the adoption of Mobile Services as a cloud backend service for mobile apps…..

Support for iOS Apps

Limiting support to Windows Store apps was an achievable and strategically positioned starting point for the Mobile Services preview. However, with a full-scale release of Windows 8 still pending, we have yet to see the impact of Windows Store apps in the mobile universe (although I’m pretty sure that apps will catch on with Windows as they have on iPad).  While app devs today may be investigating Windows Store apps as the launch of Win8 looms, everyone who is writing mobile apps for a living are writing iOS apps for both iPhone and iPad, as well as Android apps. (Hopefully, we can soon add Windows Phone 8 to this list.)

The good news that Scott just announced is that we just added support for the iOS platform to the Mobile Services preview, which means iOS developers get the following:

Just a note that support for iOS apps is still considered “in development,” in particular because support for push notifications is not yet available.

Support for Major Identity Providers

Apps need to be able to authenticate and authorize users to provide a more customized experience and a more secure partitioning of data. Mobile Services has always provided support for authenticating users, but at first this could only be done by using Live Connect with (what is now called) a Microsoft Account. This solution basically worked, but it was pretty much a Windows Store app thing that got even more difficult to configure after Windows retired their preview app registration site from last year’s BUILD conference. While providing the benefits of single sign-on for Windows Store apps and enabling you to retrieve Microsoft Account info for the logged-on user, all the authentication work is done on the client by using the Live Connect client library.

Today, in addition to using a Microsoft Account, you can also authenticate users by using a Facebook, Twitter, or Google login. Mobile Services enables you to register your app with these identity providers, register the client secret values with your mobile service, and request Mobile Services to initiate an authentication request to your preferred identity provider with a single line of code:

user = await App.MobileService

This (C#) code sends a login request from a Windows Store app to Mobile Services asking to authenticate the user with (in this case) a Facebook login. The server then handles the OAuth interaction by displaying an identity provider web page that allows a user to login:


On successful completion of the login process, Mobile Services returns a userId value—the same userId value that is used on the service-side for authorization.

Pros on this new approach:

  • Simple client code (single method)
  • Free registration with identity providers (even for Windows Store apps)
  • Users can choose their preferred login provider.


  • Mobile Services doesn’t request or store any individual user info from the identity provider, so you can’t access things like the user’s name in the client app like you can when using the Live Connect SDK.

For a complete walkthrough of this new authentication process, see Get started with authentication for Windows Store apps (or this new iOS version).

For folks writing Windows Store app with Live Connect, no need to despair. Single sign-on is still available for Windows Store apps, but you have to have a developer registration ($50) to be able to register your app just to try it out (you don’t need to actually publish your app ).

For instructions on how to still do this in a Windows Store app, see Authenticate with Live Connect single sign-on.



Glenn Gailey
Comments (0)

Skip to main content