There was a change to Azure Mobile Apps over the weekend. It was a titanic shift in how authentication is done. In short, the Azure App Service authentication gateway is out and on-stamp authentication is in. Along with that change is a new set of WindowsAzure.MobileServices SDKs to support the new logic. This article is really on “how does that affect me?”
Advantages of the new Authentication
There are several advantages of the new authentication. Firstly, you can specify additional claims. For example, you might want to include the users real name in the claims so you can display it in your mobile app. Specific claims appear in the result to the GetIdentities() call. (More on that in another post). Secondly, the management experience is streamlined across web and mobile – there is no separation any more. Finally and perhaps most importantly, authentication is per-app now. Authentication was per-resource group with the gateway. That lead to advice to place each mobile app in its own resource group. You can now group apps together as you want and let each have its own authentication settings.
Configuring the new Authentication
Since there is no longer any gateway, you have to look elsewhere for the authentication. My client application uses Microsoft Account authentication. I have a Client ID and Client Secret. If you don’t remember how I did that, refer to my recent blog post. There are four things I need to do.
- Move the Client ID and Client Secret to the new Authentication Configuration Screens
- Adjust the Redirect URI in the Microsoft Account client configuration settings
- Update your server code with the new SDK
- Update the client code with the new SDK
Step 1: Enable App Service Authentication
First off, find the Authentication / Authorization link in your applications settings blade:
Once you find it, enable the App Service Authentication, then click on the “Log in with Microsoft Account” authentication provider:
The next blade is very different from the gateway version:
The Client ID and Client Secret are hopefully obvious. Enter the original Client ID and Client Secret from the gateway. However, there are a whole bunch of new claims that you can check. These claims are accessed through the GetIdentity() call for the user. I’ve included wl.basic and wl.emails here. You should probably always check the wl.basic claim (and that is the default).
Step 2: Adjusting the Redirect URI
Once you have set up the Azure Mobile Apps side of things, you will want to adjust the Redirect URI in the Microsoft Account application settings. Go to the My Applications page and click on your application. Click on the Edit Settings link followed by the API Settings in the left hand navigation.
The URI should be https://your-site.azurewebsites.net/.auth/login/provider/callback. Most of the providers are obvious – facebook, twitter and google. The Microsoft Account is microsoftaccount. Click on Save and you are done.
Step 3: Update the Server SDK
My server side application is written in NodeJS and uses a simple application with a single table and dynamic schema. The only change I had to do was to upgrade the NodeJS SDK to 2.0.0-alpha5 to support the new authentication service. A quick push to my GitHub repository and the changes get deployed to my Azure App Service site.
Step 4: Update the Client SDK
To go along with the new authentication mechanism, you also need to update the NuGet packages for WindowsAzure.MobileServices. In your Visual Studio project, right click on References and select Manage NuGet packages… For each of the WindowsAzure.MobileServices packages you use, upgrade them to the latest beta. I use two packages – the base WindowsAzure.MobileServices (which is updated to 2.0.0-beta-3) and the WindowsAzure.MobileServices.SQLiteStore (updated to 2.0.0-beta-2) for offline sync.
I refactored my code over the weekend and as a result I have a new class – DataStore.cs. This handles authentication and offline sync capabilities for me. In the old version, the constructor for the MobileServicesClient (which was located in App.xaml.cs, but is now in DataStore.cs) had three arguments:
MobileServiceClient MobileService = new MobileServiceClient(clouduri, gatewayuri, appkey);
Well, there is no gateway any more and there hasn’t been an app key for some time. So we can now simplify the constructor:
MobileServiceClient MobileService = new MobileServiceClient(clouduri);
You can simply remove the two unnecessary arguments.
Gateway Authentication isn’t going away. You can still configure it and your clients can still use it. You should probably be running two versions of your code – one for Gateway authentication and one for the new authentication. As your users upgrade to newer clients that support the new authentication, you can use some of the new features of the new authentication scheme to great effect. That, however, is another blog post.