Nrthugu

Needing help from anyone.

I have a SPA client application that is talking to a WebApi (.Net 4.52). Both have been developed by my company. It has been working quite fine with tokens that the WebAPI has been generating itself (based on the excellent articles from bitoftech)

We now want to allow authentication with Azure - more specifically, my customer's own azure tenant (which I have no direct control over). To do this on the client-side, we use adal.js to do the back and forth with actually signing the user in, and we use UseWindowsAzureActiveDirectoryBearerAuthentication on the server-side to validate the azure tokens.

The Oauth startup looks like this:

public static void RunAcademyOAuthStartup(IAppBuilder app)

{            

        if (ConfigurationManager.AppSettings["ida:Enabled"] == "1")

        {

            app.UseWindowsAzureActiveDirectoryBearerAuthentication(

                new WindowsAzureActiveDirectoryBearerAuthenticationOptions

                {

                    TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters

                    {

                        ValidAudience = ConfigurationManager.AppSettings["ida:Audience"],

                        AuthenticationType = "ExternalAzureSSO"

                    },

                    Tenant = ConfigurationManager.AppSettings["ida:Tenant"]



                }

            );

        }





        var apiAccessTokenLifeTimeSeconds = 0;

        if (!int.TryParse(ConfigurationManager.AppSettings["ApiAccessTokenLifetimeSeconds"], out apiAccessTokenLifeTimeSeconds))

        {

            apiAccessTokenLifeTimeSeconds = 1800; //set default to 30 minutes

        }



        var oAuthServerOptions = new OAuthAuthorizationServerOptions()

        {

            AllowInsecureHttp = true,

            TokenEndpointPath = new PathString("/api/user/authenticate"),

            AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(apiAccessTokenLifeTimeSeconds),

            Provider = new SimpleAuthorizationServerProvider(),

            RefreshTokenProvider = new SimpleRefreshTokenProvider(),

            AuthenticationType = "LocalApplication"

        };



        OAuthBearerOptions = new OAuthBearerAuthenticationOptions();



        // Token Generation - setup the token authorization server

        app.UseOAuthAuthorizationServer(oAuthServerOptions);

        app.UseOAuthBearerAuthentication(OAuthBearerOptions);



}

The code above is no different to hundreds of other examples I've been trawling through for days.

This all works fine when I use my free Azure instance (through my company's MSDN) - I can authenticate, the token comes back from azure, webapi can decode it and validate and it continues on.

My problem arises when I try this against my customer's P1 Azure instance - I can authenticate, get a token back, but my webapi does not decode the token. There is no errors logged as far as I can see.

The main thing I can see at the moment is when I get the azure token and decode it using jwt.io, I can see the "x5t" and "kid" values. Based on other information I have found around the 'net, I should be able to get the latest keys from https://login.microsoftonline.com/common/discovery/keys and find either the "x5t" and/or the "kid" values in there....but I can't.

Is this possible? What would cause a token to be generated with keys other than the common ones? Is this a configuration item within the app registration in azure? Do I need to add more settings to the UseWindowsAzureActiveDirectoryBearerAuthentication config in web api?

Tokens are all v1

An answer for anyone who is coming across this thread in the future...probably a rookie mistake :)

What I found in my case was that the admin on the Azure side had registered my application using the "Enterprise Applications" option in their Azure Portal BEFORE editing the manifest,etc in the "App Registrations" area. According to Microsoft Support, it should be done the other way around - register in App Registrations first, then go to Enterprise Applications (if needed). Doing things in that order means that the azure tenant then generates the tokens and signs them with the "common" keys, and not the custom key that a Enterprise App gets.