In this tutorial, you add authentication to the Quick Start project using a supported identity provider. This tutorial is based on the Mobile Services Quick Start tutorial, which you must complete first.

Register app for authentication and configure Mobile Services

To authenticate users, register your app with an identity provider, and then register the provider-generated client credentials with Azure Mobile Services.

Log on to the Azure Management Portal, click Mobile Services, and then click your mobile service.

Click the Dashboard tab and note the Mobile Service URL value. You may need to provide this value to the identity provider when you register your app.

Choose a supported identity provider from the list below. Follow the steps to register your app with that provider. Remember to make a note of the client identity and secret values generated by the provider.

IMPORTANT:

The provider-generated secret is an important security credential. Do not share this secret with anyone or distribute it with your app.

Back in the Management Portal, click the Identity tab, enter the app identifier and shared secret values obtained from your identity provider, and click Save. Both your mobile service and your app are now configured to work with your chosen authentication provider.

IMPORTANT:

Verify that you've set the correct redirect URI on your identity provider's developer site. As described in the linked instructions for each provider above, the redirect URI may be different for a .NET backend service vs. for a JavaScript backend service. An incorrectly configured redirect URI may result in the login screen not being displayed properly and the app malfunctioning in unexpected ways.

Restrict permissions to authenticated users

By default, all requests to mobile service resources are restricted to clients that present the application key, which does not strictly secure access to resources. To secure your resources, you must restrict access to only authenticated clients.

In Visual Studio, open your mobile service project, expand the Controllers folder, and open TodoItemController.cs. The TodoItemController class implements data access for the TodoItem table. Add the following using statement:

using Microsoft.WindowsAzure.Mobile.Service.Security;

Apply the following AuthorizeLevel attribute to the TodoItemController class. This ensures that all operations against the TodoItem table require an authenticated user.

[AuthorizeLevel(AuthorizationLevel.User)]

NOTE:

Apply the AuthorizeLevel attribute to individual methods to set specific authorization levels on the methods exposed by the controller.

If you wish to debug authentication locally, expand the App_Start folder, open WebApiConfig.cs, and add the following code to the Register method.

config.SetIsHosted(true);

This tells the local mobile service project to run as if it is being hosted in Azure, including honoring the AuthorizeLevel settings. Without this setting, all HTTP requests to localhost are permitted without authentication despite the AuthorizeLevel setting.

Republish your project.

In Xcode, open the project. Press the Run button to start the app. Verify that an exception with a status code of 401 (Unauthorized) is raised after the app starts. This happens because the app attempts to access Mobile Services as an unauthenticated user, but the TodoItem table now requires authentication.

Add authentication to app

Open QSTodoListViewController.m and in the viewDidLoad method, remove the following line:

NOTE:

If you are using an identity provider other than Facebook, change the value passed to loginWithProvider. The supported values are: microsoftaccount, facebook, twitter, google, or windowsazureactivedirectory.

Press Run to start the app, and then log in with your chosen identity provider. When you are logged in, you should be able to view the Todo list and make updates.

Store authentication tokens in app

The previous example shows a standard sign-in, which requires the client to contact both the identity provider and the mobile service every time the app starts. This method does not scale and is inefficient.

A better approach is to cache the authorization token returned by Azure Mobile Services and try to use this first before using a provider-based sign-in.

The recommended way to encrypt and store authentication tokens on an iOS client is use the iOS Keychain. We'll use SSKeychain -- a simple wrapper around the iOS Keychain. Follow the instructions on the SSKeychain page and add it to your project. Verify that the Enable Modules setting is enabled in the project's Build Settings (section Apple LLVM - Languages - Modules.)