Menu

Local Debugging with User Authentication of an Azure Mobile App Service

Local debugging of an Azure Mobile App Service can be a real timesaver, however, using provider authentication such as Facebook or Google throws a wrench in process. In the past, I resorted to logging on the server side and viewing the streaming logs. This was cumbersome and not to mention time consuming. Thankfully, that can be changed. Local debugging with user authentication of an Azure Mobile App Service is now super easy.

Thanks to the documentation, I knew it was possible, but a few things weren’t entirely clear. The steps below bring everything you need to configure local debugging with authentication into one place.

I assume you are working with the following:

In the [Project]/App_Start/Startup.MobileApp.cs file of your Mobile Apps Service, add the following highlighted code:

You’ll need to grab the WEBSITE_AUTH_SIGNING_KEY for your service. This key is highly sensitive and should never be included in a client application. This should be only used on the service side.

  1. Open a browser and navigate to https://{servicename}.scm.azurewebsites.net/, replacing the {servicename}. This will take you to the Kudu settings.
  2. If you do not know your Service Name, you can find it as follows:
    1. Login to the Azure Portal.
    2. Navigate to your App Service.
    3. Click on Tools in the top bar underneath Mobile App Code.
    4. Under the Tools, find Develop and then click on Kudu in that section.
  3. You should now be on the Kudu settings site mentioned in step 1. Click on Environment on the top navigation bar.
  4. Search for “WEBSITE_AUTH_SIGNING_KEY” without quotes. It should be under the environment variable section.
  5. Copy this value for the the next section.

Still in your Mobile Apps Service, in the [Project]/Web.config, add the following highlighted code making sure to replace the {} items with their appropriate values:

In your Mobile App using Azure Mobile Services (in my case, this is for a Xamarin Mobile App) you will need the following code where you are currently instantiating your MobileServiceClient:

The key issue I was running into originally was that I did not set the AlternateLoginHost  to the actual service. This had resulted in a 404 error being displayed on my mobile app when clicking an authentication provider. Setting the this value makes all authentication calls still hit your Azure Service while your data calls hit the local service for easy debugging.

Note: This does not allow you to debug your service with authentication without an internet connection. You will still need an active internet connection, especially if your service hits other services. An example would be calling  GetAppServiceIdentityAsync<FacebookCredentials>  which calls out to the login provider service and requires an internet connection.

Being able to locally debug a service that uses authentication is an absolute timesaver. Hopefully this will help you get it up and running.

About John

John Rennemeyer is a software engineer that started his own development company MuvEnum, LLC in 2005. Born in Utah, he is a father of six, husband of one, and grandparent of none. His current programming passions include Xamarin, WPF, SharePoint, and their supporting technologies. His current non-programming passions include spending time with his family and hanging out with friends while enjoying food and fun. How's that for specific?

  • Paul

    bang on! thanks

  • Jimi

    Great post!
    It helped me a lot, finding the SigningKey and setting the AlternateLoginHost.
    A note for others developing a Cordova/PhoneGap app: note that AlternateLoginHost has a leading lowecase ‘a’ as it is javascript.
    WindowsAzure.MobileServiceClient.alternateLoginHost = “https://{servicename}.azurewebsites.net/”;

  • Bill

    I’ve done the steps you’ve suggested and I get an “unexpected packet format” whenever I try to call InvokeApiAsync. Authentication works fine with the service published to azure. Have you seen this error?
    Thanks 🙂

  • Pingback: How to add custom claims to Azure Mobile App authentication | Microsoft()

  • Mikko Korhonen

    Took few hours to figure ValidAudience and ValidIssuer must end with “/”. Anyway nice instructions. Thanks.

  • E. Timothy Uy

    Hi I use both Azure Mobile Apps and SignalR in my app. Your technique works great and results in a CurrentUser that gets authenticated. However, I find that I am not able to get my SignalR hub working as it is still unauthorized. I wonder what magic I need to get this to work.

    For SignalR, I use

    conn.Headers[“x-zumo-auth”] = _appService.CurrentUser.MobileServiceAuthenticationToken;

    with

    public class ZumoUserIdProvider : IUserIdProvider
    {
    public string GetUserId(IRequest request)
    {
    if (request == null)
    {
    throw new ArgumentNullException(“request”);
    }

    if (request.User != null && request.User.Identity != null)
    {
    var identity = (ClaimsIdentity)request.User.Identity;
    var identifier = identity.FindFirst(ClaimTypes.NameIdentifier);
    if (identifier != null)
    {
    return identifier.Value;
    }
    }

    return null;
    }

  • Stefan Schnablegger

    I’m trying to setup local debugging currently without any auth. If I do a GET on http://computername/Appx/tables/TodoItem locally it works fine but when I try to access the tables remotely its asking for ‘Basic Auth’. Any suggestions would be great, thanks!