You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 20, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 20, 2018. It is now read-only.
Revisit identity factoring and react to Auth 2.0 #651
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.
Reacted by cwe1ss, hem@hdk, Josh Garwood, Katsuyuki Sakai, zacateras and mikeandersun
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.
Reacted by cwe1ss, Jacob, Prasanna Loganathar, Magnus Grindal Bakken and fqborges
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?
changed the title [-]Split Identity into Identity.Core (User/RoleManager) / Identity.Authentication (Cookies)[/-][+]Consider removing dependency on Http for Identity[/+]on Mar 7, 2017
Activity
[-]SignInManager too tied to cookies - Adopt hooks for web API.[/-][+]Decouple SignInManager from cookies[/+]rustd commentedon Nov 30, 2015
So far Identity is based on cookies only. We can consider this in a future release.
alexsandro-xpt commentedon Dec 2, 2015
There a substitute for
Identityto work withBearertokens?brockallen commentedon Dec 3, 2015
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 commentedon Dec 16, 2015
FWIW these were split apart in 2.0
HaoK commentedon Jun 2, 2016
Moving milestone for consideration
joshgarwood commentedon Sep 20, 2016
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 commentedon Oct 26, 2016
Clearing for triage
HaoK commentedon Jan 11, 2017
@blowdart we should clean this up and use this issue to track spliting Identity Core from SignInManager + Auth
7 remaining items
[-]Split Identity into Identity.Core (User/RoleManager) / Identity.Authentication (Cookies)[/-][+]Consider removing dependency on Http for Identity[/+]HaoK commentedon Mar 7, 2017
Actually we can't since the caller needs to still pass in the HttpContext
[-]Consider removing dependency on Http for Identity[/-][+]Revisit identity factoring and react to Auth 2.0[/+]HaoK commentedon Mar 7, 2017
But still switching this bug over to track revisiting identity factoring and react to the auth 2.0 changes
HaoK commentedon May 23, 2017
e6f3ebf