Revisit identity factoring and react to Auth 2.0

[prasannavl]

The SignInManager currently is too coupled to cookies. It should ideally be able to switch methods for persistence. Currently, there's no way to use the SignInManager and enable a simple token style authentication using either the standard Bearer tokens, or a custom headers which are required for pure API services.

Either that, or the SignInManager should be moved into a namespace that emphasizes that most of its functionality only work with cookies. Shouldn't be under a very generic purview.

[rustd]

So far Identity is based on cookies only. We can consider this in a future release.

[alexsandro-xpt]

There a substitute for Identity to work with Bearer tokens?

[brockallen]

So far Identity is based on cookies only. We can consider this in a future release.

Sorry Pranav, but this concept makes no sense. Cookies authenticate users in a browser and are unrelated to ASP.NET Identity. An identity management library (such as ASP.NET Identity) is what stores and validates users credentials. It's really independent of the consuming application. These two "things" are separate because you don't have to use them together. Conflating cookie authentication and identity management is not helpful.

I suspect it was easier to just put the SignInManager into the same assembly as the UserManager, and thus say "we are based on cookies", but it's a disingenuous answer. The part that helps with issuing cookies should be in its own assembly. The core of ASP.NET Identity should not have a dependency on HTTP.

The separation will be important once you consider other types of authentication, such as OAuth2 (and not the OAuth2 authentication middleware that's in ASP.NET 5).

Related: the brute-force code in the SignInManager should be in the core and separate from the code that manages the cookies. You will want those features from the OAuth2 endpoints.

[HaoK]

FWIW these were split apart in 2.0

[HaoK]

Moving milestone for consideration

[joshgarwood]

Is this still not finished? Which is to say, are we not able to use signInManager if we're using JwtAuthentication? I'm using .Net Core and jwt tokens, but would also like to leverage signInManager... is this possible yet? Or is there another recommendation you could make?

[HaoK]

Clearing for triage

[HaoK]

@blowdart we should clean this up and use this issue to track spliting Identity Core from SignInManager + Auth

[HaoK]

If we do this we should revisit whether we want to keep CancellationToken at all

[brockallen]

If you do this, then some of the APIs on SignInManager should be moved to UserManager (the ones that do lockout/brute-force prevention are the first ones that comes to mind).

[HaoK]

Due to aspnet/Security#1113, we can remove the dependency on Http by depending directly on the new IAuthenticationService, and removing the default wireup to RequestAborted, we can either eliminate the CancellationToken on the stores entirely, or expose some kind of CancellationToken Source service or property on UserManager

[HaoK]

Actually we can't since the caller needs to still pass in the HttpContext

[HaoK]

But still switching this bug over to track revisiting identity factoring and react to the auth 2.0 changes

[HaoK]

e6f3ebf