As I mentioned in my initial post about Project X, one of the things I need to contend with in this app is backend data storage. I’m not expecting to have a very complex or large data model but based on some of the social features I’m planning on implementing, user data will need to be stored in some sort of backend data store. I have plenty of experience modeling data and building SOAP and RESTful services on top of said data model for CRUD operations. For Project X, I could certainly take the approach of building out my own data model, coding RESTful services for CRUD operations and hosting these services somewhere in the cloud. That being said, when I think of all the work that is going to go into Project X before it ships, building out these services just doesn’t sound that interesting to me. It seems like in this day and age, there should be a better option than a bunch of repetitive coding of services that do little more than persist objects in some backend store. As it turns out, there is a better option and this option is known as backend-as-a-service.
Briefly, backend-as-a-service is a cloud based model for easily linking applications, generally mobile applications to services such as data storage, identity management, push notifications and social network integration. While I haven’t done a ton of research of backend-as-a-service offerings, I have looked at a number of different providers and one thing they all seem to have in common is that they require you to write little to no code on the backend to achieve data persistence from your client application. Instead of creating database tables, writing data access code and service code on top of that, with backend-as-a-service you simply define the name of an entity you wish to store on the backend. On the client you then model that entity with whatever attributes you wish to store and using the SDK for your backend-as-a-service provider you are able to persist and retrieve these entities from the provider’s cloud based data storage.
Windows Azure Mobile Services is Microsoft’s backend-as-a-service offering. It’s currently a preview offering as part of the Azure suite of services but looks to be quite full featured. Features include:
- Data storage: This is built on top of SQL Azure however it does allow you to have dynamic schemas so you don’t model your entities on the backend.
- Scheduled jobs
- Push notifications: This includes support for push to iOS, Android and Windows clients.
- Social network identity integration: This includes support for logging into your apps with Twitter, Facebook, Google and Microsoft accounts
Similar to Windows Azure Websites, Mobile Services currently offers two options. You can deploy your services in a shared compute environment for free or pay for the ability to scale up to 10 dedicated compute instances. In both the free and dedicated pricing models you still end up paying for data storage at whatever your plan rate is.
I’ve been looking at using WAMS from a Xamarin app for a couple of weeks now and I have to say, it is indeed very easy to persist and retrieve data from the cloud. I also had the opportunity to try out authentication with the Twitter provider as well as push notifications while I was at the Xamarin Evolve conference. Getting the Twitter auth setup was ridiculously easy. The hardest part was getting registering my app with Twitter and trust me, that wasn’t hard at all. Push notifications were a bit more frustrating to get setup but that’s more because push notifications in general are difficult to setup due to Apple’s certificate based security model. Seeing how easy it is to work with data in WAMS and social network authentication has me strongly considering WAMS as my backend service for Project X. That being said, before I commit to using WAMS, I want to spend a bit more time working with the authentication functionality. Specifically I’d like to take a look at working with the other social authentication providers they support. I’d also like to explore the possibility of doing custom authentication for those two or three people out there who don’t already have a login with Facebook/Twitter/Google/Microsoft and don’t want to sign up with one of these. Fortunately I’ve found a couple of really good blog posts that go through setting up the various providers, integrating with them and even setting up custom authentication. Unfortunately, these posts were all around building clients with Objective-C or Java so I’ve decided to put together a series of posts on doing this with a Xamarin.iOS app. Specifically I’m going to break this down into three posts:
- Part I: Configuring social authentication providers (this is what you’re currently reading)
- Part II: Building an app and integrating it with Twitter, Facebook, Google and Microsoft authentication
- Part III: Custom user registration and authentication
This probably goes without saying, but the first thing you’re going to need is a Windows Azure account. If you don’t already have one, head over to the Windows Azure website and sign up. You can get a free 90 day trial, however you do need to provide a credit card that will be charged in the event you go over the amount of service you’re allocated for your trial. Once you have your account, login to the Azure management portal and create a new mobile service. I’m not going to walk through how to do this as there are plenty of good references that will do a better job of this than I could.
Configuring Microsoft Authentication
Once you’ve created your service, head on over to Microsoft’s Live Connect Developer Center. This is where you’ll register your Xamarin app with Microsoft. Here you’ll click the Create Application link under the My Applications section:
On the next screen you just need to enter a name for your application and click the I Accept button:
After accepting, the next screen will present you with your Client ID and Client Secret which we’ll need to enter into the Azure Portal. Before we do that however, we need to enter a value for Redirect Domain:
For Redirect Domain, we just enter the Mobile Service URL found in the Dashboard screen in the Azure management portal for the mobile service we created earlier. You’ll want to keep this URL handy as we’ll be using it to configure our other authentication providers. Note that in the image above, I’ve blurred out both Client ID and Client Secret because, well, these should be kept secret. Once you’ve entered your redirect domain, copy your Client ID and Client Secret from this screen and head back over to the Azure management portal and find the identity settings for the mobile service you created. Here you’ll see fields to enter your Client ID and Client Secret that you saved, so go ahead and do that:
Once you’ve entered your Client ID and Client Secret, click the Save button at the bottom of the portal window. That’s it for your Microsoft account. Next we’ll take a look at Facebook.
Configuring Facebook Authentication
Now that we’re on to setting up our second provider, you’ll start to see a common pattern: Create your app on the provider’s developer portal, provide a callback URL and copy/paste some values from the provider’s portal to the Azure portal. Indeed, that’s what we’ll be doing with Facebook to get it setup. First, head over to the Facebook Developer site. If you haven’t already registered as a Facebook developer, you’ll have to do that first but it’s quite painless. After you’ve registered and logged into the developer site, click the Apps menu at the top of the screen and then click the Create New App button:
After you click Create New App, you’ll get a dialog where you’ll need to enter a name for your app. You can skip the app namespace and since we’re talking mobile apps, you definitely don’t need Heroku:
After clicking Continue you’ll need to enter a CAPTCHA. Head back to the Azure management portal and copy the URL for your mobile service again then scroll down the page for your app on the Facebook site and click the checkbox next to Website with Facebook Login and enter the URL for your mobile service into the textbox that appears:
Click the Save Changes button at the bottom of the screen then head to the top of the screen and copy both the App ID and App Secret values for your app. You’ve probably already guessed the next step but if not, head back to the Azure management portal and find the Facebook section on the Identity tab for your app. There you’ll need to enter the App ID and App Secret values you just copied:
Click the Save button at the bottom of the screen and you’re now ready to start accepting logins from Facebook users. Next we’ll move on to Twitter.
Configuring Twitter Authentication
To get started with Twitter, we need to navigate over to the Twitter developer site. After you login, find your Twitter avatar in the upper right hand corner of the screen, mouse over it and click the My Applications item on the menu that appears:
After you click My Applications, click the Create New Application button. On the following screen you’ll need to fill in some information about your app:
Provide a name and a description for your app. For both Website and Callback URL, provide the URL of your mobile service, which as with the other providers, you can find on the Azure management portal. Scroll down, agree to all the legal terms, enter the CAPTCHA and click the Create New Twitter Application button. After we click the Create button, we need to head over to the Settings tab. Scroll down and find the checkbox labeled Allow this application to be used to Sign in with Twitter:
Check the checkbox then scroll down and click the Update button. Head back to the Details tab and then look for the OAuth Settings section. This is where you’ll find the Consumer Key and Consumer Secret values that you’ll need to copy over to the Azure management portal:
On the Azure management portal, navigate back to the Identity tab, scroll down to the Twitter section and enter your Consumer Key and Consumer Secret from the Twitter site:
Once again, we click Save at the bottom of the screen. We’re now done with Twitter and ready to move on to our last authentication provider, Google.
Configuring Google Authentication
To get started configuring Google, head over to the Google API Console. After you login, click the dropdown on the upper left hand side of the screen and then click the Create item on the menu:
After clicking Create, we’re next prompted to name our project:
In the menu on the left hand side of the screen, click the API Access item:
On the API Access screen, your one and only option is a rather large button labeled Create an OAuth 2.0 Client ID so go ahead and click that. On the next screen you’ll be presented with a few fields to fill in. All we need to provide is a Product Name:
Go ahead and click Next. If you don’t already have it memorized, head back to the Azure management portal and copy your mobile service URL. On this screen we’ll need to enter the host name for our mobile service. Leave the Application Type set to Web Application. To the end of the host name, we want to add the text /login/google. So if our mobile service URL is https://mobileservice.azure-mobile.net, on this screen we would enter mobileservice.azure-mobile.net/login/google. Note that after you enter your host name + /login/google, the /login/google part will be automatically removed but will still be reflected in the Redirect URI field.
Go ahead and click the Create client ID button. You should now see some information including your Client ID and Client Secret. Go ahead and copy these values because, yes, you guessed it, we’re going to head back to the Azure management portal, click the Identity tab for our mobile service and scroll down to the settings for Google:
After you’ve entered your Google Client ID and Client Secret, click Save at the bottom of your screen. And with that, we’re done. Assuming we got all of our copying and pasting of values into the correct fields for our providers, we should now be ready to accept logins from Twitter, Facebook, Google and Microsoft account users. In the next post we’ll go through how to build a Xamarin.iOS app that uses the Azure Mobile Services SDK to authenticate via our four providers. Fortunately, that code is a lot less hassle than all of the copy/paste action that was required to setup the providers!
Finally, I’d like to give a big thanks to Chris Risner. His blog post on configuring the various authentication providers in WAMS mobile services saved me a ton of time an aggravation!