Strategies for deleting a logged-in user in ASP.NET Core Identity

Question

In my ASP.NET Core MVC application, an administrator may wish to delete a regular user from their organisation. This of course is trivial using the built-in Identity model, using the UserManager<T>.DeleteAsync() method.

However, the user may be logged in on multiple devices at the time. I don't need real-time messaging - I'm happy for the deleted user to be returned to the login page upon their next request. SignalR feels like an overkill for this situation.

Request.User.Identity.IsAuthenticated remains true during their session, even though their account has been deleted from the backing store.

My thought process is to override OnActionExecutingAsync() on the base controller and check for a valid record in the backing store upon each request and then take appropriate action (eg signout + redirect to login), but this feels like a significant overhead to perform on each request, especially since the backing store is CosmosDb and this will cost extra Request Units.

I also need to consider AJAX requests as significant pages within the MVC application have dynamic elements and the user might stay on a single page for a long time.

What's the most effective, lightweight way to check if their user account has been deleted upon next request?

Answer 1

You are right, checking upon each request is inefficient. Since you mentioned that an administrator wants to be able to delete manually, a couple of seconds delay between deleting and forcing a logout won't be a problem (it's the same as deleting a couple of seconds later).

Upon defining that you are using .NET Core Identity, you can simply define SecurityStampValidatorOptions , such as

services.Configure<SecurityStampValidatorOptions>(options =>
{
    options.ValidationInterval = TimeSpan.FromMinutes(1);
});

This results in the user token being validated every minute. If you set the ValidationInterval to .FromMinutes(0) , the token is being validated upon each request (I think it's like 3 database call for verifying). My suggestion would be not to take 0 as a value, but rather a value that you think is acceptable for the timespan between a user being deleted manually and him being forced out of the application.