Openiddict-core: Possible to disable Identity cookies when using JWT tokens?

[replaysMike]

Is it currently possible with .net core 2.1 to disable cookies completely?

I have JWT setup but noticed the calls to /connect/token and subsequent controllers all still return Identity cookies named .AspNetCore.Identity.Application. I'd love to be able to turn these off completely, haven't come across a way to do it yet.

[kevinchalet]

I believe it's now possible in 2.1 but I haven't tried it and I have no idea what the syntax is.

Since this is mainly an Identity question, I'll let @HaoK point you to the right direction.

I have JWT setup but noticed the calls to /connect/token return Identity cookies

It's definitely not the expected behavior (and it's particularly unsafe, as it's essentially a session fixation flaw). Are you using PasswordSignInAsync() instead of CheckPasswordSignInAsync()?

[kevinchalet]

@HaoK feel free to move this discussion to the Identity repo if you think it's a better place.

[HaoK]

It should be possible even in 2.0, if you stop using SignInManager and use AddIdentityCore() instead of AddIdentity. 2.1 will add some extra sugar that builds on AddIdentityCore but doesn't really change anything from 2.0

[kevinchalet]

It should be possible even in 2.0, if you stop using SignInManager and use AddIdentityCore() instead of AddIdentity.

I frankly doubt that's a reasonable suggestion. Validating the username/password/lockout/status without the sign-in manager is an absolute pain path.

FWIW, registering the Identity services without the cookies middleware was possible in 1.x...

[HaoK]

Well this isn't an explicitly supported scenario for SignInManager as it has calls that depend on the identity cookies, but generally things should work if you steer clear of any of those... i.e. only call 'safe' operations like CheckPassword.

Its reasonable to file an issue asking for some new mechanism to use identity and some subset of sign in functionality only via UserManager...

[kevinchalet]

I'll open a new thread after dinner.

I guess we can add this feature to the list of things that used to work in 1.x and that regressed in 2.0.

Le 22 mars 2018 à 21:33, Hao Kung [e-mail] a écrit :

Well this isn't an explicitly supported scenario for SignInManager as it has calls that depend on the identity cookies, but generally things should work if you steer clear of any of those... i.e. only call 'safe' operations like CheckPassword.

Its reasonable to file an issue asking for some new mechanism to use identity and some subset of sign in functionality only via UserManager...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[HaoK]

Why don't things continue to work as they did before here? Identity didn't change much in 2.0

[HaoK]

Any method that resulted in a SignIn or Authenticate in 1.x wouldn't work if the cookies didn't exist either

[kevinchalet]

@HaoK things are not broken on our side: @replaysMike is looking for a way to use the Identity user validation APIs without all the cookies stuff, which makes no sense in an API app. In 1.x, you could do that by not calling app.UseIdentity(). In 2.x it's not possible.

[HaoK]

Sure you can, call AddIdentityCore which doesn't add any auth stuff, Add sign in manager explicitly if its being used, that's equivalent to how things were in 1.x more or less.

[HaoK]

Identity was pretty much unchanged from 1.x to 2.0, other than how you configure the cookie options which isn't an issue here.

[kevinchalet]

So the final syntax is something like that?

services.AddIdentityCore<ApplicationUser>(options => { })
    .AddEntityFrameworkStores<ApplicationDbContext>()
    .AddDefaultTokenProviders()
    .AddRoleManager<RoleManager<IdentityRole>>()
    .AddSignInManager<SignInManager<ApplicationUser>>();

services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();

If it is the right approach, that would be worth documenting it somewhere. That's not the first time I hear that question.

Identity was pretty much unchanged from 1.x to 2.0, other than how you configure the cookie options which isn't an issue here.

In 2.0, app.UseIdentity() is no longer a thing. To support the same scenario, removing a single line is no longer possible: you now have to go lower-level and manually add back the sign-in and role managers. It's not super painful, but definitely not something most people are naturally comfortable with.

[kevinchalet]

This topic seems to confirm that's really a common scenario: https://github.com/aspnet/Identity/issues/1376.

[HaoK]

There's no doubt that people keep trying to do this, which is why we added the AddIdentityCore overload, but SignInManager is still designed to work with cookies in general, only some of the methods work (and by accident as opposed by intent). Hence there won't be official documentation support for identity + JWT in general since only some thing work right now...

[kevinchalet]

So you've added an overload to support a scenario you don't recommend and that only works by accident? Okay...

Thanks for the info.

[HaoK]

The supported scenario is to let you use identity services without auth/cookies, not to enable JWT + SignInManager scenarios. If users can get things to 'work' via mixing and matching some auth services and core identity, that's fine, but that's why you won't see documentation or samples

[kevinchalet]

The supported scenario is to let you use identity services without auth/cookies, not to enable JWT + SignInManager scenarios.

Where did you see it was "JWT + SignInManager"? It's SignInManager.CheckPasswordSignInAsync without any of the cookie stuff. It has nothing to do with JWT. You'd have exactly the same problem if you only wanted to validate a username/password couple in a console app.

If users can get things to 'work' via mixing and matching some auth services and core identity, that's fine, but that's why you won't see documentation or samples

Yeah, it's much better to let folks ask the same question again and again :sweat_smile:

[HaoK]

If all you want to do is check the password, use UserMangaer.CheckPassword

[kevinchalet]

If all you want to do is check the password, use UserMangaer.CheckPassword

Add the lockout handling + the "is allowed login status" and it's way less trivial.
You agreed to introduce CheckPasswordSignInAsync() in 1.1. I believe that was a good reason for that, no?

Ultimately, I think the real problem is that it was added to the wrong place.

[HaoK]

Its in the right place, the problem is all the authentication logic is tied to sign in manager which is tied to cookies in general. Which is why I asked for the issue, there's no quick and easy fix, using sign in manager without cookies is always going to be hack (it also happens to be the only thing you can do today to use things like CheckPasswordSignIn), so it will never be officially supported/encouraged

[kevinchalet]

// Ensure the user is allowed to sign in.
if (!await _signInManager.CanSignInAsync(user))
{
    return BadRequest(new OpenIdConnectResponse
    {
        Error = OpenIdConnectConstants.Errors.InvalidGrant,
        ErrorDescription = "The specified user is not allowed to sign in."
    });
}

// Reject the token request if two-factor authentication has been enabled by the user.
if (_userManager.SupportsUserTwoFactor && await _userManager.GetTwoFactorEnabledAsync(user))
{
    return BadRequest(new OpenIdConnectResponse
    {
        Error = OpenIdConnectConstants.Errors.InvalidGrant,
        ErrorDescription = "The specified user is not allowed to sign in."
    });
}

// Ensure the user is not already locked out.
if (_userManager.SupportsUserLockout && await _userManager.IsLockedOutAsync(user))
{
    return BadRequest(new OpenIdConnectResponse
    {
        Error = OpenIdConnectConstants.Errors.InvalidGrant,
        ErrorDescription = "The username/password couple is invalid."
    });
}

// Ensure the password is valid.
if (!await _userManager.CheckPasswordAsync(user, request.Password))
{
    if (_userManager.SupportsUserLockout)
    {
        await _userManager.AccessFailedAsync(user);
    }

    return BadRequest(new OpenIdConnectResponse
    {
        Error = OpenIdConnectConstants.Errors.InvalidGrant,
        ErrorDescription = "The username/password couple is invalid."
    });
}

if (_userManager.SupportsUserLockout)
{
    await _userManager.ResetAccessFailedCountAsync(user);
}

That's what we did in 1.0. Certainly more complicated than a single call to CheckPasswordSignInAsync().

[HaoK]

Yeah the issue is basically that some of this logic needs to live in user manager as opposed to sign in manager. Not to use sign in manager in more places.

[HaoK]

UserManager = User + store operations manipulating the user
SignInManager = UserManager + authentication + cookies

That's the way to think of things as they were designed (from the pre core days)

[kevinchalet]

That's why I said CheckPasswordSignInAsync should have been added to UserManager instead of SignInManager. It was added because Brock Allen needed a way to do the same checks without returning a cookie (which is what PasswordSignInAsync does). Since SignInManager is the place where you deal with cookies, this new cookie-less API was probably not a good candidate for this class.

[HaoK]

SignInManager has all the logic that deals with signin in today, I don't disagree that all this stuff needs a good refactoring, it all predates core even, and was based on Owin authentication originally...

That said, its going to be a fairly hard sell for me to get yet another auth related rewrite/refactor approved :)

[kevinchalet]

That said, its going to be a fairly hard sell for me to get yet another auth related rewrite/refactor approved :)

That's fine. The current approach is not perfect, but it does the job and is not hyper complicated . I just wish a snippet, a comment or a link to the Identity post was added somewhere to help folks achieve what they want without asking again and again the same question :laughing:

[replaysMike]

oh wow, I walked away for a day and this thread blew up lol. Yes, I'm building a single page app and everything will route through the api. I'm attempting to do everything completely without cookies and rely on JWT/Local storage. I did add a quick hack (completely just a temporary hack) by placing:

Response.Cookies.Delete(".AspNetCore.Identity.Application");
Response.Headers.Remove("Set-Cookie");

right before returning from the ExchangeAsync() controller method. It works, but obviously not the ideal solution.

I'm still absorbing the content in this thread, will review it all closely and respond

[kevinchalet]

Closing, as I believe your issue should now be fixed. Let us know if you're still having problems with your config.

[pfaner]

I done everithing and it works but when I check is the user is logged in asp.net Core Razor login page it fails. SignInManager.IsSignedIn(User) returns allways false. How I can acces to JWT Claims in Razor Pages?

[lonix1]

@PinpointTownes or @HaoK or anyone else - this issue is so frustrating, confusing... and common!

SignInManager contains the auth-goodness, e.g. lockout, email confirm, etc. But it is meant for cookies.

UserManager is meant for JWT, but doesn't have those features, so we need to re-implement them.

Is there an example implementation somewhere? I don't want to reinvent the wheel :cry:

[i-akash]

in dotnetcore web api ,it works well when we use this combination

                  signInManager.PasswordSignInAsync();
                  Response.Cookies.Delete(".AspNetCore.Identity.Application");