Security stamp validation for bearer tokens?

[mguinness]

Does security stamp validation occur with bearer tokens when using Identity API endpoints?

For example, consider the following sample setup:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthorization();

builder.Services.AddIdentityCore<AppUser>()
    .AddEntityFrameworkStores<AppDbContext>()
    .AddApiEndpoints();

builder.Services.AddAuthentication()
    .AddBearerToken(IdentityConstants.BearerScheme); 

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

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapIdentityApi<AppUser>();

I would anticipate using the following code would prevent this user from accessing endpoints with RequireAuthorization after several minutes with the configured ValidationInterval for SecurityStampValidatorOptions.

await userManager.SetLockoutEndDateAsync(user, DateTimeOffset.UtcNow.AddHours(12));
await userManager.UpdateSecurityStampAsync(user);

However, it doesn't appear to work. Looking at #47228 authored by @halter73 it makes reference to both security stamp validation and bearer tokens. But is that only during token refresh, i.e. ISecurityStampValidator only works with cookies?

Just trying to get my head around the concepts as the documentation is lacking in this respect and possibly needs addressing if my assumptions are incorrect.

[halter73]

it makes reference to both security stamp validation and bearer tokens. But is that only during token refresh, i.e. ISecurityStampValidator only works with cookies?

ISecurityStampValidator is only designed to work with the cookie authentication handler. That's why ISecurityStampValidator.ValidateAsync takes a CookieValidatePrincipalContext. And even with cookies, the ISecurityStampValidator only checks the database after a certain timeout to avoid hitting the DB and every single request which is based on the ValidationInterval.

As you noted, the bearer token handler does not rely on SecurityStampValidator.cs or ISecurityValidator at all, so it takes no notice of SecurityStampValidatorOptions.ValdationInterval. What it does do, is call SignInManager.ValidateSecurityStampAsync during token refresh in a similar way to the default SecurityStampValidator.

The easiest way to make this validation occur more frequently is to reduce BearerTokenOptions.BearerTokenExpiration to match what you want your ValidationInterval to be. So in this case, it would be reducing the default of 1 hour to 1 minute.

The security stamp check is limited to token refresh requests instead of checked on every request to avoid hitting the DB every single request. Unlike with cookies, we cannot just reissue a token when the client is not expecting it. So, if we let you set the validation interval independently of the refresh interval, you could run into significant perf issues.

Take the 1-minute validation interval example. If we allowed you to validate the security stamp for every request with a token over a minute old, but we still let you keep the refresh interval at an hour, you would only spare hitting the database the first minute after you've refreshed the token. You'd be forced to check the database for every request for the next 59 minutes until the client refreshed the token again, or we'd be forced to keep state in a server-side cache which we try to avoid by default.

If you have custom validation logic that's inexpensive enough that it can run on every request without reissuing any cookies or tokens, I think the easiest way to achieve that now is to write custom middleware that runs after the authentication middleware and just does the validation every request.

I agree it's a good idea to update our documentation to cover MapIdentityApi's security stamp support and how it works.

[mguinness]

Thanks for the reply Stephen, I appreciate you taking the time to elaborate.

I'm familiar with cookie auth and the corresponding performance hit with ValidationInterval, but I didn't really have a handle on how that worked in relation with bearer tokens. I did end up lowering BearerTokenExpiration and based on your response that was the correct approach.

As you say, the middleware approach is an alternative if you have specific requirements. There's no free lunch so you have to make compromises. Another option would be to use websockets or SSE to push the token invalidation to the client.

I don't know if this issue can be moved to the AspNetCore.Docs repo as it might be more appropriate there. I still don't have a clear understanding on token expiration in relation to access/refresh - the client can still obtain a refresh token after ExpiresIn has passed? I read that typically the refresh token has a longer duration that the access token, but I'm having difficulty finding documentation relating to identity that discusses this.

[mguinness]

OK, I found the answer regarding the duration of the refresh token. Now I've got a much better grasp of how these tokens are generated/used.

aspnetcore/src/Security/Authentication/BearerToken/src/BearerTokenOptions.cs

Lines 34 to 41 in 1e1e2f7

	/// <summary>
	/// Controls how much time the refresh token will remain valid from the point it is created.
	/// The expiration information is stored in the protected token.
	/// </summary>
	/// <remarks>
	/// Defaults to 14 days.
	/// </remarks>
	public TimeSpan RefreshTokenExpiration { get; set; } = TimeSpan.FromDays(14);

[mguinness]

Created PR dotnet/AspNetCore.Docs#36622 to include my learnings.