I’m working on a new project that’ll be targeting both Windows Phone 8 and Windows 8. My hope is that this baby will end up being quite a big deal so I am actually giving Azure a good, hard, look. My first use case is that I’d like to have users log in to my app with accounts they already have – not have to create a new username/password for my app that they have to remember and store somewhere.
Enter Azure’s new Mobile Services offering. Along with a database for your app to store stuff, AMS provides another sweet little tool: Authentication.
AMS’ authentication allows you to tie Microsoft Account, Google, Facebook, AND Twitter authentication in to your app. Now, a couple of those will limit your app and make you pay past a certain point (ahem: Google (1mil/day), Twitter (100k all-time)), but the other two are pretty sweet.
For the most part, setting these things up is pretty simple, but there are enough nuances that I thought a blog post might help some folks out.
Let’s get started. Microsoft is really pushing Azure as of late and the coolest thing is that you an actually get a FREE Azure account at the “pay-as-you-go” price level just to play with these kinds of things and see how they’ll work out for you and/or how far you want to take your Azure backend.
My opinion? I think that Azure doesn’t have much to stand on when it comes to indie developers like myself due to the lack of a steady, affordable, cost. If I create a free app using the backend and it takes off like nobody’s business, I could very well end up with a $1000 bill for month X that I could never afford. That would suck. But, things like Federated Authentication might just be “light,” powerful, and useful enough that hobbyists might pick it up more readily once they see what it can do.
First, sign up for a free Azure 90-day trial by starting at the signup page.
You’ll need a phone and credit card – they swear it’s only for identity verification. A quick text message and input of a verification code and:
Now head to your portal by clicking
in the upper-right hand corner of the screen.
Feel free to read through the tutorial to get the full gravity of what you’re about to play with 
Now behold the wonder of the beautiful, fluid, web experience the Azure team has created. Seriously, it’s gotta be one of the more impressive parts of using Azure. It’s just damn sexy.
Start by just following the suggestion:
Go ahead and ‘Create an Item’
Choose ‘Compute’ | ‘Mobile Service’ | ‘Create’
Pick a subdomain name you’re proud of and a region closest to where you’re at, just for sanity’s sake:
When creating a new SQL instance, pick that you want a new SQL server and a user/pass you’re comfortable with as well. For Authentication services you won’t need to be using the SQL server that Azure sets up by doing these steps, but it’s part of the setup so we’ve gotta go thru it. If you pick a different reason than what you chose for your Mobile Services, you’ll get a warning. Don’t bother with the Advanced Settings for now.
You’ll now see this awesomesauce at the bottom of your Azure Portal screen:
Hey what can I say, I’m not a web developer so these kinds of tidbits impress me.
Once that finishes up, you’ll have your service staring you in the face, begging to be messed with:
Time to start playing. Click the name of the service, which will launch in to its configuration pages. The cool part here is that not only has Azure set you up with your mobile service, their Quick Start page actually GIVES you a FULL SOLUTION for Windows 8, Windows Phone, or *bah* iOs that is pre-configured with your service’s URL and Authentication Key. Pretty sweet as far as getting up and running goes.
You don’t need to bother downloading that just yet, though.
The part of our new AMS we want to set up is the Identity part. So click that:
Once you’re there you’ll see what information we require to set up the Authentication points from Microsoft, Facebook, Google, and Twitter. This is the part that hung me up for a while. It was easy to find these pieces from those sources, but not the most intuitive to set up my AMS instance to work with them. That is, it’s easy to know how to plug them in to AMS, but not easy to know how to plug AMS in to them. So lets walk through each of the services now.
For Microsoft Account, your developer portal is located at dev.live.com. Once there, log in with a Microsoft Account that you’d like to associate w/ this (only used to manage applications that utilize the Live SDK) and head to the “My Apps” page. If this is your first app, you’ll be taken directly to the ‘Create’ page.
On the Create page, pay attention to the instructions. Some of the fields you’re filling out will be displayed to your end users (i.e.: “Application X wants to access your data, are you cool with that?”).
After creation, you’re taken directly to the API Settings page for your new application, where you’re given all the information you need to wire this up to your new AMS instance.
Take the Client ID and Client secret and punch those in to the right spots in the Identity area of your AMS instance that’s staring you in the face on your other browser tab:
Now at first glance you think you’d be done, but you’d be wrong. In your Live API settings, leave ‘Mobile client app’ set to ‘No’ and place your AMS Instance’s URL in the Redirect URL box
Click ‘Save’ in your Live app’s API settings.
That’s it. Microsoft Account integration is now wired up – which we’ll see in a bit.
Next, let’s tackle Facebook. In much the same fashion, we’ll repeat what we did for the Microsoft Account integration but put the Client ID and Secret from Facebook in to the relevant fields of our AMS’ Identity area, and give Facebook the correct Redirect URL so that the auth flow works as desired.
Disclaimer: I don’t have a Facebook account so the setup and screenshots are from me being logged in to my wife’s so forgive the lack of showing everything on the page 
Head to developers.facebook.com, log in, click Apps. Create a New App, fill it out much like we just did for our Live API application.
For Facebook, you put the AMS’ URL in to another spot, the “Website with Facebook Login” area:
And that’s it. Facebook done.
NEXT, Google. Head to the Google API Console, log in, and Create a new Project.
Google by creates an “API Project” which is fine for our purposes. On the left side, choose “API Access” and then Create an OAuth 2.0 Client ID:
Here’s where we, again, put in our Application information that users will end up seeing when they attempt to log in. But with Google there is one important difference so observe these screens closely:
Notice the little bit on the end of our AMS instance’s base URL – without that the Google API won’t work properly. Go ahead and create the Client ID then, and you’ll get your, now familiar, Client ID and Client Secret which we put in the usual places of our AMS’ Identity area.
And last but not least, Twitter. Head to their developer portal’s app management area and log in. Then Create a new Application. You know what you’re doing by now, right?
There we go, pre-setup complete! Now let’s head back to have a look at that slick little Windows 8 Visual Studio Solution that our Azure AMS Instance pre-fabbed for us.
To get back to that handy Quick Start screen, click this little dude:
Now go ahead and download the pre-fabbed Windows 8 solution:
The pre-fabbed solution will give you the ability to read, insert, and update records in the “TodoItems” table that is created by that first green button there. No matter, we’re going to write completely new code to exercise our authentication flows. We won’t worry about securing the data in this blog post – I just wanted to show how to get this wired up since some of it is a bit unintuitive.
So, once you have the solution downloaded, extracted, and building, we’ll make some code changes. When you initially get the app, it looks something like this:
We’re going to change it to this:
So to do that, add the following code to the XAML:
<Grid Grid.Row="1"
Grid.Column="0"
Grid.ColumnSpan="2"
HorizontalAlignment="Center"
Margin="0,0,0,30">
<StackPanel Orientation="Horizontal">
<Button Name="MSLoginButton"
Click="MSLoginButton_Click"
Content="Microsoft Login" />
<Button Name="TwitterLoginButton"
Click="TwitterLoginButton_Click"
Content="Twitter Login" />
<Button Name="GoogleLoginButton"
Click="GoogleLoginButton_Click"
Content="Google Login" />
<Button Name="FBLoginButton"
Click="FBLoginButton_Click"
Content="Facebook Login" />
</StackPanel>
</Grid>
And adjust the other Grid.Row properties of the other items accordingly, of course.
Now wire up the code behind:
async private void MSLoginButton_Click (object sender, RoutedEventArgs e)
{
await Authorize (MobileServiceAuthenticationProvider.MicrosoftAccount);
}
async private void TwitterLoginButton_Click (object sender, RoutedEventArgs e)
{
await Authorize (MobileServiceAuthenticationProvider.Twitter);
}
async private void GoogleLoginButton_Click (object sender, RoutedEventArgs e)
{
await Authorize (MobileServiceAuthenticationProvider.Google);
}
async private void FBLoginButton_Click (object sender, RoutedEventArgs e)
{
await Authorize (MobileServiceAuthenticationProvider.Facebook);
}
async private System.Threading.Tasks.Task Authorize (MobileServiceAuthenticationProvider mobileServiceAuthenticationProvider)
{
try {
var user = await App.MobileService.LoginAsync (mobileServiceAuthenticationProvider);
if (user != null) {
var d = new Windows.UI.Popups.MessageDialog (user.UserId);
await d.ShowAsync ();
}
} catch { }
}
Boom that should do it!
Microsoft Account:
Twitter:
Google:
and finally Facebook:
And that’s it, folks! Hope this helps out aspiring Windows 8 & Windows Phone developers looking to wet their chops with Azure and AMS!