Authenticating in Azure but calling web api on localhost – 401 – Twitter API

I have an Azure mobile app authenticating on azure with FB and Twitter. I am able to login to both but when testing web api calls locally (hosted in IIS) – any controller with the Authorize attribute – returns a 401.

The alternateLoginHost is set to the Azure host and it is providing me with a token after a successful login.

I followed the instructions in the docs about setting up Local debugging with authentication.

It is using attribute based routing – config.MapHttpAttributeRoutes()

Here is my full OWIN startup class

public class OwinStartup
{
    public void Configuration(IAppBuilder app)
    {
        HttpConfiguration config = new HttpConfiguration();

        config.MapHttpAttributeRoutes();

        new MobileAppConfiguration()
            .ApplyTo(config);

        app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
        {
            SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
            ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
            ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
            TokenHandler = config.GetAppServiceTokenHandler()
        });

        app.UseWebApi(config);

    }

I have seen references in the documentation about either using the global http config passed in from asp.net or creating a new one – I tried referencing the GlobalConfiguration.Configuration instead of creating a new instance but it didn’t help.

Is there a way to hook into the OWIN pipeline to see if the token is making it to the app service authentication module?

[EDIT] ZUMO AUTH HEADER
I am also adding the x-zumo-auth header and setting it’s value to the token from the current user like this

request.headers.append('X-ZUMO-AUTH',
app.azureClient.currentUser.mobileServiceAuthenticationToken)

And I can see it in each request being made to the api. A call to the endpoint https://mysite.azurewebsites.net/.auth/me using this mechanism is returning a correct response so I know the token is valid.

[EDIT] Verified working in Azure after adding ZUMO Version Header
deployed the web api to azure and tried to call my web api endpoint and received a bad request error. It turns out it required an additional header for the version

'ZUMO-API-VERSION', '2.0.0'

I added the header and it worked.

Tried the local call again with the version header but still getting 401.

All I can assume is the OWIN middleware is not receiving the token probably due to a config problem – need some transparency into the pipeline to test some of these theories – not sure the best way to do that

Not sure where to look next in solving this.

[EDIT] OWIN Pipeline Authenticate stage Hook
OK – figured how to set up the equivalent to asp.net pipeline event handlers in OWIN – in my startup file I added this code to execute when the Authenticate stage is reached

        app.Use((context, next) =>
        {
            return next.Invoke();
        });
        app.UseStageMarker(PipelineStage.Authenticate);

Added a breakpoint and when the debugger stops I can see that in the call stack
that the Azure App Service Middleware in in the pipeline

Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware
<Microsoft.Azure.Mobile.Server.Authentication.AppServiceAuthenticationOptions>
.Invoke(Microsoft.Owin.IOwinContext context)

Confirmed OWINContext.Request.Headers Contains the Correct Auth Token

Looking in the debugger the token is indeed in the Context.Request.Headers collection at the Authenticate stage of the OWIN pipeline and it has the correct value. For some reason still receiving the 401 status

I doubly checked the value I am using for the SigningKey – copied from the WEBSITE_AUTH_SIGNING_KEY value in Azure.

[EDIT] Debugging with source and exception being thrown in ValidateIdentity

AppServiceAuthenticationHandler.ValidateIdentity

Downloaded source v1.1.157.1, loaded symbols from symbolsource but those are marked as 1.0.157.1 and visual studio is complaining that the source is different than when the module was built. Because of this I cannot step through the code to see the exception that is being caught.

[EDIT]Built and Referenced v1.1.157.1 DLL – exception type now visible

In the ValidateIdentity method when it calls

options.TokenHandler.TryValidateLoginToken

The following exception is thrown

"Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken' 
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'."

[EDIT] Finally found and fixed the issue

There was an issue posted on GitHub for IdentityServer having to do with a breaking change with a nuget package – going from v4 -> v5 of System.IdentityModel.TokensJwt package.

https://github.com/IdentityServer/IdentityServer3/issues/3017

I downgraded my install to v4.0.x and it fixed the exception and also fixed the 401 errors I was seeing when running locally.

All is good now