title: Multiple Authentication Schemes ASPNET Core 3
body: <p><strong>See Update below</strong></p>
  <p>I'm using Azure AD B2C and I'd like my users to be able to log in thru my web app as well as be able to utilize JWT bearer tokens and call Web API methods from a mobile app.</p>
  <p>I can get either authentication scheme to work by itself. For example, in my startup.cs I can do the following:</p>
  <pre><code>        services
              .AddAuthentication(AzureADB2CDefaults.AuthenticationScheme)
              .AddAzureADB2C(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options));
  </code></pre>
  <p>which works as expected (a user can login on the web site, but JWT doesn't work).</p>
  <p>Alternatively, I can instead use the following and then only JWT bearer tokens will work:</p>
  <pre><code>        services
              .AddAuthentication(AzureADB2CDefaults.JwtBearerAuthenticationScheme)
              .AddAzureADB2CBearer(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options));
  </code></pre>
  <p>If I want either to work, I can do the following (with the help of <a href="https://stackoverflow.com/a/49706390">https://stackoverflow.com/a/49706390</a>)</p>
  <pre><code>        services
              .AddAuthentication()
              .AddAzureADB2C(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options))
              .AddAzureADB2CBearer(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options));
  
          services.AddAuthorization(options =&gt;
          {
              options.DefaultPolicy = new AuthorizationPolicyBuilder()
                                      .RequireAuthenticatedUser()
                                      .AddAuthenticationSchemes(AzureADB2CDefaults.AuthenticationScheme, AzureADB2CDefaults.JwtBearerAuthenticationScheme)
                                      .Build();
          }
  </code></pre>
  <p>And now either will work. (edit: actually, they don't work completely)</p>
  <p>HOWEVER, I also have this code:</p>
  <pre><code>        app.UseAuthentication();
          app.UseMiddleware&lt;MyAfterAuthenticatedMiddleware&gt;();
          app.UseAuthorization();
  </code></pre>
  <p>The problem is that when I use the combination of either authentication, when my middleware code runs, my user is not authenticated (in the middleware code) and has no claims, etc. but obtains them later in the pipeline.</p>
  <p>What's happening here? And how can this be fixed?</p>
  <p>It <em>seems</em> that when I don't specify a default authentication scheme--in order to have multiple schemes--the authentication is not happening until the authorization step in the pipeline.</p>
  <p>I need my middleware to run after authentication and before authorization.
  How can I make that happen with the multiple authentication schemes?</p>
  <p><strong>UPDATE</strong> -- <strong>Solved! But there must be a better way!??</strong></p>
  <p>First of all, to the people who have created the .NET security stuff, I say kudos. It's important and it's difficult. <em>However</em> I do think there may be a lot of room for improvement.</p>
  <p>Most developers dabble in security when they have to, and then go back to their &quot;regular&quot; job&quot;. Unless you work with it every day, it's tough to keep on top of. Every time you go back to it, everything's changed yet again.</p>
  <p>It must be a common scenario: I want my users to be able to log in to my web site and interact with various web API methods. I would like them to also be able to access those same API methods via another means, such as a mobile app--where I'd be using JWT tokens, or equivalent.</p>
  <p>This shouldn't be hard to make work.</p>
  <p>However, I was tying myself into knots creating handlers for this and policies for that. One thing would work, but another thing wouldn't. Then when I thought things were right--I discovered some of the <strong>challenge and forbid logic didn't work as expected</strong>.</p>
  <p>The built-in Authorization middleware has the ability to do authentication -- this was one of the early roads I went down, only to discover that it didn't fully work -- and it caused other problems for me, as described above.</p>
  <p>In my opinion, <strong>authentication should <em>not</em> happen during authorization</strong>. Authentication should happen where it is expected--in authentication middleware. (My guess is that it was added in authorization in order to work around some other problem that presented itself years ago -- and perhaps still exists today)</p>
  <p>Anyway--here is how I finally got things to work. It could be a lot cleaner and slicker and more flexible, but it works for my needs. And it is less of a hack than anything else I have seen. But is there a nicer, built-in class that could have done this for me?</p>
  <p>My new question is this: <strong>is there a better way to get this done than how I've done it as described below?</strong>. It's hard to believe this is the best way.</p>
  <p>In Startup.ConfigureServices I have now have the following:</p>
  <pre><code>services
     .AddAuthentication(AzureADB2CDefaults.AuthenticationScheme)
     .AddAzureADB2C(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options))
     .AddAzureADB2CBearer(options =&gt; Configuration.Bind(&quot;AzureAdB2C&quot;, options));
  </code></pre>
  <p>I then also have:</p>
  <pre><code>services.AddHttpContextAccessor();
  services.AddSingleton&lt;IAuthenticationSchemeProvider, MyAuthenticationSchemeProvider&gt;();
  </code></pre>
  <p>And finally, I have a new class:</p>
  <pre><code>public class MyAuthenticationSchemeProvider : AuthenticationSchemeProvider
  {
      public MyAuthenticationSchemeProvider(IOptions&lt;AuthenticationOptions&gt; options, IHttpContextAccessor httpContextAccessor) : base(options)
      {
          HttpContextAccessor = httpContextAccessor;
      }
  
      protected MyAuthenticationSchemeProvider(IOptions&lt;AuthenticationOptions&gt; options, IDictionary&lt;string, AuthenticationScheme&gt; schemes, IHttpContextAccessor httpContextAccessor) : base(options, schemes)
      {
          HttpContextAccessor = httpContextAccessor;
      }
  
      private IHttpContextAccessor HttpContextAccessor { get; }
  
      private bool IsBearerRequest()
      {
          var httpContext = HttpContextAccessor.HttpContext;
          return httpContext.Request.Headers.ContainsKey(&quot;Authorization&quot;)
                  &amp;&amp; httpContext.Request.Headers[&quot;Authorization&quot;].Any(x =&gt; x.ToLower().Contains(&quot;bearer&quot;));
      }
  
      public async Task&lt;AuthenticationScheme&gt; GetMySchemeAsync()
      {
          return IsBearerRequest()
              ? await GetSchemeAsync(AzureADB2CDefaults.BearerAuthenticationScheme)
              : await base.GetDefaultAuthenticateSchemeAsync();
      }
  
      public override async Task&lt;AuthenticationScheme&gt; GetDefaultAuthenticateSchemeAsync()
      {
          return await GetMySchemeAsync();
      }
  
      public override Task&lt;AuthenticationScheme&gt; GetDefaultChallengeSchemeAsync()
      {
          return GetMySchemeAsync();
      }
  
      public override Task&lt;AuthenticationScheme&gt; GetDefaultForbidSchemeAsync()
      {
          return GetMySchemeAsync();
      }
  }
  </code></pre>
  <p>Now I can use both kinds of authentication, the challenge &amp; forbid work as expected. Why isn't there a built-in class that allows for switching between authentication schemes? Why does the authorization middleware attempt to authenticate with multiple schemes (I say it shouldn't do it at all), but not the authentication middleware?</p>
  <p>Now this is here for anyone else who struggles with a similar issue.</p>