Authenticating users in Windows Azure Mobile Services

In my previous post about Mobile Services, I talked about how to get started with the service. I also promised that I would follow up with a post about how to authenticate the users, so that is what this post is going to be about.

You currently have 4 different options when it comes to authentication, Microsoft ID (previously Live ID), Facebook, Twitter and Google. They are all 3rd party services, and requires your users to have accounts with one of the providers. Luckily, most users already do. And the neat thing about using 3rd party authentication is that you don’t have to care about handling sensitive data such as usernames and passwords. And leaving that to someone else is making your life a lot less complicated. Not to mention that having Mobile Services handle all of the actual interaction with them makes your life ridiculously simple, as you will see.

I must admit that I would have loved to see the Mobile Services authentication run through ACS instead. That way, it would have been easy for us to set up authentication through ADFS and other identity providers, but I guess we can’t have it all…at least not at once…

Ok, so how do you set up your Mobile Service to support authentication? Well, it is actually a piece of cake… First you have to decide what identity provider to use, or if you want to support several of them. In this post, I will focus on using Facebook.

Once you have decided what identity provider to use, you have to configure the identity provider for you application. As mentioned, I will use Facebook, so I browse to and click the “Apps” menu item. If you have never used the developer part of Facebook, it is not that complicated to get started. Next, I click “Create New App” at the top right corner, which pops-up the following “window”


All you need to do here is to add a unique “App Name” and press continue. And after you have figured out the captcha that you are faced with, you get the following view


The last thing you need to do in here is to click the “Website with Facebook Login” link and fill in the url to the Mobile Services endpoint you are going to use. In my case, that will be, so I will it out like this


Ok…that’s pretty much all you need to do to configure Facebook. Just press “Save Changes” and you are done. The next step is to set up the Mobile Services integration, which is actually just as easy. Just go to the top of the Facebook app page, and locate the “App ID” and “App Secret”, these need to added to the Mobile Services settings in the Azure Portal. So, just browse to the settings page for the Mobile Service you want to work with, and click the “IDENTITY” link.


If you then look just below the settings for microsoft accounts, you will find “facebook settings”, and 2 textboxes with very familiar labels. Just copy your App ID and App Secret from the Facebook developer portal into these, press “SAVE” and confirm that you want to update the settings.

That’s it! Authentication configured…now all there is left to do, is to get the actual application to use it, which once again is a walk in the park.

In my case, I have added a Login button to my application, and hooked up a handler for the click event.

<Button Content="Login" Click="LoginLogoutClick" />

In the click handler, I verify whether or not the current user is logged in or not by checking if the CurrentUser property is null. If it is, it is time to log in, if not, it is time to logout.

private async void LoginLogoutClick(object sender, RoutedEventArgs e)
if (App.MobileService.CurrentUser == null)
await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
if (App.MobileService.CurrentUser != null)
((Button) sender).Content = "Logout";
new MessageDialog("You are now logged in [" + App.MobileService.CurrentUser.UserId + "]").ShowAsync();
((Button)sender).Content = "Login";
new MessageDialog("You are now logged out").ShowAsync();

As you can see, the Mobile Services proxy handles all of it for us. All that is needed is to call LoginAsync(), passing in the identity provider to use, and it does the rest. Remember that logging in is async though, so it need to be “awaited”. Logging out however is synchronous, so we don’t need to “await” it. The result of calling LoginAsync() in an App Store application looks like this


And after entering my credentials, I am requested to authorize the Facebook application to get basic information from Facebook.


And I am then finally greeted by a MessageDialog like this


As you can see, the user id is just a string, which consists of the identity provider, a colon and a unique id given to the service by the identity provider. In the case of Facebook, it is the user id of my Facebook account, but you should not assume that it will always be that…

Ok, so what now? What can we do now? Well, you now have a user identity to use when you save data in your service, which is really useful. And the cool thing is that this is a one-time thing. The user doesn’t need to sign in everytime the application starts, the Mobile Services proxy handles all of that for us…

So say that I wanted to store a name and e-mail address for my user. This is really simple. All you need to do is give the user a UI to insert the information, and then use a little bit of code like this

private void SaveUserDetailsClick(object sender, RoutedEventArgs e)
var msg = new JsonObject {{"name", GetName()}, {"email", GetEmail()}};

As you can see, I do not pass the user id with my entity. I do not trust passing it as part of the message, as the user could easily modify the data being sent to the server and set other users information. Instead, the best practice in this case is to use an insert script and set the user id on the server instead.

To do this, I go to the scripts section for my table, and modify the insert script as follows

function insert(item, user, request) {
item.userId = user.userId;

Thus making sure that the user id is added to the table…but also making sure that it is the correct user id.

Now, to secure the table, I also make sure that only authenticated users can perform operations on the table by setting the permissions as follows


That’s it! A few settings, some copy pasting and a line of two of code, and you have authentication and authorization built in to your application back end. Very simple if you ask me…

Comments (5) -

Ryan CrawCour 12/4/2012 7:50:26 AM

Great post! Nice and simple to follow. Good job.


Could I automatically get the name of the Facebook user through something like loggedIn["first_name"], or won't facebook allow this?

I went for a simple solution where I fetched JSON from with the user.UserId fetched from Facebook's Azure auth guide. Works!

Yeah, that works. However, I wouldn't bet my life on the format of the user id. I'm pretty sure that could potentially change without warning...

I have two questions:
1)Does userId is constant and never change?
2)What can I do with this userId? Can I use I as row ID in my table?

Pingbacks and trackbacks (1)+

Add comment