Q:

Proper way to extend the authentication middleware in .NET Core 2.0

I'm trying to figure out what is the right way to extend the authentication in .NET Core 2.0 WebAPI project.
I'm using Identity with Entity Framework stores. I've configured the services to support authentication using AddAuthentication() and UseAuthentication().
I'm using JWT tokens for authentication via AddJwtBearer(). Now I want to add APIs to handle two things for me:

Validate username and password and issue a JWT token if there's a match in the Entity Framework Identity Store. This part is pretty easy and I can achieve it by simply injecting the SignInManager into my Account controller.
If the user is not found I want to use a custom authentication flow and validate if the user is present in a different "place" and if there's a match - create a user in the Identity Store. Now that's what I'm trying to figure out the best approach for.

The only thing that comes to mind is to build this login flow into my Account controller, validate the username/password via EF Identity Store, then validate using my custom store and if a match is found - call the "new user" methods manually from the Account controller. However, this approach does not feel right to me because in .NET 1.1 this was addressed by building your own authentication middlewares. However, I can't find any documentation for .NET 2.0 approach.
What is the best way to solve the problem?

A:

This seems more of a style/design issue.  
A) You can indeed put everything into an AccountController, during the 'login' you can just add the 'registration' to be part of it (in case you find an 'external' match for the user credentials), pretty much as you suggested.  
I don't see a huge downside to doing just that (though I often prefer middleware myself as you can more 'configure' things in startup).  
Design wise, there is probably an issue synchronizing your external provider with the internal identity store (if that's what's the case, usually is), but that goes for either of these options. Often introducing a specialized authorization server may solve that but I don't know enough specifics so just guessing.  
B) if I'm reading you write what you want,
to add the auth. middleware I used something like this (based on it):
TokenProviderMiddleware
(that GitHub solution is a very good example)  
Basically (to summarize some of that code):
You call something like the app.UseTokenProvider(); from the Configure (startup). 
app.UseTokenProvider(_tokenProviderOptions);  
// or directly (w/o the extension method)
app.UseMiddleware<TokenProviderMiddleware>();  
...

...and the TokenProviderMiddleware has a certain signature to satisfy (injecting the next in the chain into the .ctor and the public Task Invoke(HttpContext context) 
This allows you to skip the controller, or as much as you'd like to do that. 
Not sure if this solves your troubles but it helped me with something similar.

