Milan Nankov

Milan Nankov

Migrating Custom Authentication With Azure Mobile Services To Mobile Apps

Mobile Apps is, at the time of writing, in public preview but it is here to stay for sure and anyone using Azure Mobile Services will have to consider migrating to Mobile Apps sometime in the future. There is already an article that outlines the migration process, but it lacks guidance as to how one is supposed to migrate existing custom authentication functionality to Mobile Apps. Fortunately the process should be relatively painless as you will see in a minute. But before we dig into the concrete steps, I would kindly ask you to go over and read my blog on custom authentication with Mobile Apps first, which covers the basics that we will be referring to in this article.

Mobile Apps vs. Mobile Services - The Differences

Now that we have solid understanding of custom authentication with Mobile Apps, lets summarize how Mobile Apps differ from Azure Mobile Services with regard to custom authentication.

No LoginProvider class

Implementing custom authentication involved creating a custom LoginProvider class where things like token lifetime and token deserialization are configured. The login provider class is no more - there is no need to inherit from a base class to have custom authentication. Yes, you can create your own class to encapsulate the related logic, but it is up to you to decide how to do that.

No ProviderCredentials class

LoginProvider and ProviderCredentials were a pair of classes that you had to inherit from. As expected, since there is no LoginProvider, there is no ProviderCredentials as well. So you do not have to worry about this class also.

Use Authorize instead of AuthorizeLevel

Protecting resources with Mobile Services required the use of custom attribute called AuthotizationLevel. With Mobile Apps we use the standard Authorize one.

Tokens are signed with WEBSITE_AUTH_SIGNING_KEY

Azure Mobile Services used the master key to sign authentications tokens. There is no such key for Mobile Apps, but there is a new one called WEBSITE_AUTH_SIGNING_KEY, which is available as an environment variable. It is now time to take a look at the actual steps that are needed to port custom authentication to Mobile Apps. Let's get to work.

Migrating Custom Authentication To Mobile Apps

We are now going to migrate a custom authentication implementation for Azure Mobiles Services to Mobile Apps. Here is the code:

Step 1: Created Tokens using AppServiceLoginHandler.CreateToken instead of CustomLoginProvider

The purpose of CustomLoginProvider in Azure Mobile Services is to generate JWT tokens that authenticate users. To do the same with Mobile Apps we use AppServiceLoginHandler.CreateToken. So the main difference is that we have previously used a class whereas we now use a simple method call. The CreateToken method seems quite complex at first, but most of its parameters should be familiar:
  • Claims - these are the claims that we want to be included in our JWT token. These are equivalent to the claims that are used with CustomLoginProvider.
  • SigningKey - this is the key that the JWT tokens are encrypted with. With Azure Mobile Services the master key was used as signing key. Now we use a special environment variable called WEBSITE_AUTH_SIGNING_KEY to get our signing key.
  • Audience & Issuer - These are parameters that we haven't used or set when using Mobile Services.  These should simply match the url of your Mobile Apps service.
  • Lifetime - This field specifies when a token expires. This is equivalent to the TokenLifetime property of CustomLoginProvider.
  I've encapsulated the token creation logic in a method called GetAuthenticationTokenForUser. This method is roughly equivalent to CustomLoginProvider.CreateLoginResult. So our migrated token creation code looks like this:

Step 2: Modify Authentication Controller to Use GetAuthenticationTokenForUser

Our token creating code is ready, let's modify the authentication controller to use this new piece of code. Usually, you will update only a couple of lines of code of your controller since we are only swapping the code that generates the token itself. The core of your authentication logic (for example, checking a password against a database) should remain intact.

We have changed only 3 lines of our original code. Pretty neat, right?

Step 3: Change AuthorizeLevel to Authorize

Mobile Apps uses the standard Authorize attribute to protect resources. Simply replace all AuthorizeLevel attributes with Authorize and we are good to go. Here is how our protected controller looks after the migration:

In Closing

Migrating custom authentication to Mobile Apps should be relatively straightforward since your core authentication logic should remain intact - the only code that should change is the one that creates the authentication token. I hope that this article is helpful and as usual any comment or suggestions are more than welcome.

Need consulting on this topic?

Yes No