Milan Nankov – Blog

Azure Mobile Services – Configuring The OWIN Pipeline 2014/08/30

At some point you might need to plug into or configure the OWIN pipeline that is used by Azure Mobile Service. The purpose of this post is to demonstrate 3 ways to achive this. Let’s get started.

The 3 ways that we are going to look at today are:

  1. StartupOwinAppBuilder.Initialize()
  2. Using a custom IOwinAppBuilder
  3. Using a IOwinAppBuilderExtension

Before we actually look at each item individually I will summarize how OWIN is configured in Azure Mobile Services.

If you take a look at Microsoft.WindowsAzure.Mobile.Service.dll you will see that the entry point of OWIN configuration is a class called StartupOwinAppBuilder. The entry point is specified with the help of the OwinStartup attribute.

StartupOwinAppBuilder does not actually configure OWIN but in fact it delegates the configuration. By default, AMS (Azure Mobile Services) will look for a class that implements IOwinAppBuilder and that implementation will be invoked by StartupOwinAppBuilder. The class OwinAppBuilder is one such implementation and it will be used by default. This is where the actual OWIN configuration of AMS is conducted. Now that we understand how Azure Mobile Services starts the OWIN configuration process, let’s learn how we can actualy plug into it.

Using StartupOwinAppBuilder.Initialize()

With Microsoft.WindowsAzure.Mobile.Service.Config.StartupOwinAppBuilder.Initialize() you can set a delegate that will be used to configure the OWIN pipeline. The catch here is that by using StartupOwinAppBuilder.Initialize you actually override the default delegate that has been selected for you by the framework. All of the default OWIN configurations fly out the window and you are on your own. Basically this is the most drastic measure – in most cases the other two options will better suit your needs.

Using a custom IOwinAppBuilder

The second approach is to create our own IOwinAppBuilder implementation and plug that into the OWIN initialization process. Since we normally want to only add to the default OWIN configuration we will inherit from the built-in OwinAppBuilder class – that way we can easily add additional configuration steps  instead of overwriting the whole process.

The only thing left to do now is tell ASM to use our custom builder. All custom implementation like IOwinAppBuilder are resolved using Autofac – the DI framework used by Azure Mobile Seervices. To enable this scenario we have to make minor modifications to our WebApiConfig.Register() method.

Once we have registered our builder instance, ASM will be able to locate it and use it. Something to have in mind is that only one IOwinAppBuilder can be used at a time, i.e, even if you have registered 10 builder instances, only the last registered builder will be invoked. 

Using IOwinAppBuilderExtension

The last option is the least invasive one. Similarly to the IOwinAppBuilder, we just have to implement a simple interface. The difference here is that we cannot override the default OWIN configuration and we can register as many IOwinAppBuilderExtension types/instances as we fancy. Behind the scenes the framework is using the built-in OwinAppBuilder and at some point of its OWIN configuration flow it gets all IOwinAppBuilderExtension types and executes them one by one. Pretty neat.

And here is how we register the extensions:


Are you using any of the three methods that are outlined here? Do you like the current options?


  • Chase Oliphant

    This is a fantastic example. I’ve been searching for an example like this for days. Thanks!

  • Milan

    Thanks! I am glad that the post has been helpful. Let me know if I can help you with anything.

  • Chase Oliphant

    Thanks, I have a question for you. Maybe you may have come across this before:
    I created a AMS using the 3rd option covered above to configure my OWIN pipeline. Your example works perfectly for me when debugging locally. However, when I publish to Azure and send a request from the AMS to the server I get “500/Internal Server Error” and a response message that says “{“message”:”An error has occurred.”}.” I checked to make sure my cloud based production db connection string would work when debugging locally. Initially, I thought maybe it could be an issue with the connection string when deploying to Azure so then I added the connection string for my db context to the Azure configure tab and I still get the same response/error. Any idea what the issue could be when deploying to azure?

  • Chase Oliphant

    FYI, I just checked the logs in Azure and I see the following error message. I’m currently researching how to fix it but haven’t found anything that works yet. —–> Exception=System.TypeLoadException: Could not load type ‘CultureAwaiter`1′ from assembly ‘Microsoft.AspNet.Identity.Core, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35′.

  • Aidan Casey

    Hi Milan

    I’ve added your blog post to a curated list of azure mobile services resources – “Awesome-AzureMobileServices”
    feel free to add to the list via a github pull request

    thanks !

  • Milan

    Hello Aidan,

    Sorry for the delayed response. This is great news. I really appreciate that.
    I have recently moved this article to the blog section of our company where we have better code formatting and we regularly check for comments. Is it possible to update the link for this article on to point to ?