Azure Mobile Services Tip: What To Do if Your API Key Became Public

DZone 's Guide to

Azure Mobile Services Tip: What To Do if Your API Key Became Public

· ·
Free Resource

Azure Mobile Services is a data infrastructure product offered by Microsoft that allows developers to easily hook their applications to a simple data source (e.g. table) for further consumption, among other things, such as notifications. 

Let's say I have a Windows Phone 8 application that I have connected to AMS. To get data, I probably would create a MobileServiceClient instance like this:

public static MobileServiceClient MobileService = new MobileServiceClient(
This does not seem to be a big problem, until you decided that a project should go open-source. How do you handle data access? Do you give a bunch of strangers direct access to your database? What happens if someone decides to abuse that power?

The pragmatic approach here would be the right approach - strip the URL and the API key from the client and ship the product on CodePlex or GitHub (or any other project hosting site). This procedure can also be optimized if you have a build script that will automatically erase those whenever you prepare a configuration that will go public.

But what to do if you accidentally checked-in your code with the URL and key in? There are two scenarios that you can tackle:

1. Reset the key.

This is the best solution in this case, and it is done in a couple of clicks.

Click on Manage Keys and use the Regenerate button on the keys you'd like to reset. Start with the Application Key only - reset the Master Key only if absolutely necessary.

However, this solution implies that your application is not available anywhere else (e.g. a platform-specific Store/Marketplace). Resetting the key will automatically block access to your data in any application instances that are using the old key, and since in most cases the application key is hard-coded - you might have a couple of unhappy users. Is there anything you can do to improve your predicament with users in mind? Yes, which leads us to the next scenario.

2. Limit access to your data.

By default, when the application key is created, it allows data insertion, removal and querying. If that is the case, you don't want anyone who is not you, but who has the key, to tamper with the content you are making available through AMS.

First of all, open the CONFIGURE tab and disable Dynamic Schema:

This will prevent another person from inserting custom-crafted models that do not abide the guidelines that you have established for your data. Now, you need to set what one can do with the application key.

Open the table that you want locked for any input, and open the PERMISSIONS tab.

Notice that for every option, but READ, I have set that only scripts and admins can perform the specified actions. As for READ, the application key remains viable and anyone using the application can still access the data, but in read-only mode. Which means that whoever has the key will also be able to read raw data fetched from AMS, but at least they won't be able to harm the overall user experience. 

Gradually, you will need to redeploy a new version of the app with a new application key, or establish a web service endpoint that would fetch the authenticating string through a HTTPS channel in a dynamic way, that way giving you the ability to easily update the key on all clients.

Obviously, all this should be done before your application even ships - ensure that nobody will be able to tamper with the data, because the AMS key can be extracted from an app in more than one way. However, these are also actions that should be applied as soon as possible in case a key becomes public.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}