401 with AAD B2C authentication in an admittedly complex setup


  • My setup is three separate Azure Web Apps, an Angular2 application (Client) and two deployments of the same ASP.NET Core web application, one compiled targeting .NET Core 1.1 and the other targeting .NET Framework 4.6.2 (WebApiCore and WebApiFramework respectively). The goal is for these three applications (Client, WebApiCore and WebApiFramework) to share authentication.

    Toward this end I created an Azure Active Directory B2C instance with a single application and a single policy (sign-in/sign-up). The only application specific data I had to add when setting up B2C was a reply URL in the B2C application definition. That URL links to the Client application.

    The Client application has a single setting for the API URI which it uses to pull all data. When I have that value set to the WebApiCore URI everything works perfectly. I can log in with a B2C user and the Client app retrieves data from both unsecured and secured resources on WebApiCore. However, if I set the API URI to the WebApiFramework URI I get a 401 any time I attempt to access secured resources (unsecured resources function normally).

    This is behaving like my B2C application has some affinity to the WebApiCore application or maybe the combination Client+WebApiCore but I don't understand how that would be possible as there's no settings specific to WebApiCore anywhere in my B2C. I did deploy and test WebApiFramework last but that alone seems like an unlikely reason.

    Any thoughts you might have will be appreciated.

    Sunday, March 19, 2017 6:20 AM

All replies

  • Make sure that WebApiFramework is configured properly. For debugging the issues and for configuring it correctly you can refer to this documentation on Azure Active Directory B2C: Build a .NET web API in the following link -
    Tuesday, March 21, 2017 7:22 PM
  • That help document is specifically for .NET Framework. That is not my scenario. My project is an ASP.NET Core project.

    The WebApiFramework deployment is 100% identical to the WebApiCore deployment with the exception that the former is compiled targeting .NET Framework 4.6.2 and the later .NET Core 1.1. The WebApiCore deployment works perfectly but the WebApiFramework deployment returns 401 when accessing any secured resource.

    Tuesday, March 21, 2017 8:11 PM
  • I've done some further work with this and the root cause of the 401 from the WebApiFramework app has something to do with the target framework compile and not an affinity to the original working WebApiCore site.

    I created two additional Azure Web Apps WebApiFramework2 and WebApiCore2. As implied I published the ASP.NET Core application with the target frameworks net462 and netcoreapp1.1 respectively. By changing the API URI in my Client app I've found that WebApiCore and WebApiCore2 are working perfectly while WebApiFramework and WebApiFramework2 both return 401 if they access a secured resource (again open resources work correctly).

    This seems quite strange to me. I'd expect any difference in target framework compilation significant enough to suddenly fail would throw and exception and likely return 500 but it this situation it's clearly about authentication. 

    Here's my .csproj file. I simply comment out the framework I wish to exclude before publishing (with an accompanying clean and re-build  before the publish of course).

    <Project Sdk="Microsoft.NET.Sdk.Web">
        <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
        <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
        <PackageReference Include="Microsoft.AspNetCore.Server.IISIntegration" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Server.Kestrel" Version="1.1.1" />
        <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Configuration.FileExtensions" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />
        <PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Diagnostics" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Authentication" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="1.1.1" />
      <ItemGroup Condition=" '$(TargetFramework)' == 'net462' ">
        <Reference Include="System" />
        <Reference Include="Microsoft.CSharp" />

    Again, any thoughts or suggestions will be appreciated.

    Saturday, March 25, 2017 3:45 AM
  • We would suggest you to open a Technical Support Request with us as we would require sensitive information like your Subscription and Tenant details and for deeper investigation on this.
    Thursday, March 30, 2017 8:37 AM