Is there any way to lock out a user? Could this be added?

[SoftCircuits]

I need a way to lock out a user. Not from too many login attempts. But because I want to deny them access to the site without deleting their account.

I've found you can set LockoutEnd to a date and time in the future, and that user will not be able to log in. However, by default, users don't need to log in every time they go to the site. The site remembers their login for something like 30 days. So they would be able to continue using the site for up to 30 days!

Is there any way to lock them out immediately?

Is there any way this sort of feature could be baked in? Does this require me to write my own middleware? If so, has anyone done this already?

[danroth27]

There isn't currently a convenient built-in way to do this. You could invalidate the security stamp and then check for that in a cookie authentication event. We can consider making this easier in the future.

[SoftCircuits]

@danroth27 Thanks for the reply. Unfortunately, this isn't an area I'm that familiar with. I don't suppose you'd have a link showing your suggestion in more detail?

[halter73]

The site remembers their login for something like 30 days. So they would be able to continue using the site for up to 30 days!

The default value for CookieAuthenticationOptions.ExpireTimeSpan is 14 days, and SlidingExpiration is true by default, so someone might stay signed indefinitely without reentering their password as long as they refresh their cookie at least once every two weeks. These defaults can be overridden though. So, depending on your needs, if you just need to lock someone out withing a day for example, you could do something like the following:

builder.Services.ConfigureApplicationCookie(cookieAuthOptions =>
{
    cookieAuthOptions.ExpireTimeSpan = TimeSpan.FromHours(24);
    cookieAuthOptions.SlidingExpiration = false;
});

https://learn.microsoft.com/en-us/aspnet/core/security/authentication/cookie?view=aspnetcore-9.0
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.cookies.cookieauthenticationoptions?view=aspnetcore-9.0

Somewhat orthogonally, you can also limit the cookie to persist just for the duration of the current browser session (which can last an arbitrarily long time, so don't treat this as a replacement for expiration), you can use isPersistent: false for your call to SignInManager<TUser>.PasswordSignInAsync(TUser user, string password, bool isPersistent, bool lockoutOnFailure)

var result = await _signInManager.PasswordSignInAsync(Input.Email, Input.Password, isPersistent: false, lockoutOnFailure: true);

https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-9.0&tabs=visual-studio#log-in

Of course, this would force everyone to log in every 24 hours or every new browser session (whichever comes first if you do both) even if they're not locked out. You might also want to lock people out immediately or at least with less than a 24-hour delay. It's more complicated, but this is where Identity's security stamp feature is helpful. It's basically a random value that's stored inside the cookie and the database that has to match for the user to authenticate. So, after you update LockoutEnd, you can call UserManager<TUser>.UpdateSecurityStampAsync(TUser user) and the given user will be forced to attempt to sign in again (which will of course now fail due to the lockout) as soon as the SecurityStampValidatorOptions.ValidationInterval elapses which defaults to only 30 minutes.

If you need to reduce to ValidationInterval, I recommend not going below one minute, but you can lower the ValidationInterval all the way to TimeSpan.Zero if you desire. Just beware that setting the validation interval to zero can have a significant perf impact since it forces an extra database query for every single request that needs to validate the cookie.

https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-configuration?view=aspnetcore-9.0#isecuritystampvalidator-and-signout-everywhere
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.securitystampvalidatoroptions?view=aspnetcore-9.0
https://dotnetdocs.ir/Post/31/invalid-cookies-after-changing-users-passwords

#32318 (comment) explains why we don't call UpdateSecurityStampAsync automatically inside of SetLockoutEndDateAsync. Basically, it'd be an easy denial of service attack vector. But if you're setting a lockout for some reason other than failed access attempts or anything else that could be triggered by an anonymous attacker, it could be reasonable to manually update the security stamp manually after setting up the lockout in order to force close active sessions.

[SoftCircuits]

@halter73 Wow! Greatly appreciated. Thanks!