Security stamp validator in jwtBearerMiddleware - oauth-2.0

Question

I've a oauth2 resource server which uses the JwtBearerMiddleware to validate the access tokens. Now I wan't that the access token is invalid if the security stamp has changed. As it looks like this middleware doesn't validate the security stamp by itself.
I've found the SecurityStampValidator class which only seems to validate cookie authentication.
Where and how do I have to validate the security stamp from my json web token?
My current way to do it is to register an eventhandler for the OnTokenValidated event when I register the JwtBearerMiddleware. In this eventhandler I simply query the database for the security claim and compare it with the one in the token. When the security stamp isn't the same I just set the Ticket and SecurityToken of the context to null and skip to the next middleware which eventually will throw an 401 http status code if authentication is required.
app.UseJwtBearerAuthentication(new JwtBearerOptions
{
...
Events = new JwtBearerEvents
{
OnTokenValidated = async (ctx) =>
{
var securityStampClaim = ctx.Ticket.Principal.Claims.FirstOrDefault(claim => claim.Type == "AspNet.Identity.SecurityStamp");
var subjectClaim = ctx.Ticket.Principal.Claims.FirstOrDefault(claim => claim.Type == OpenIdConnectConstants.Claims.Subject);
if (securityStampClaim == null || subjectClaim == null)
return;
var user = await userStore.FindByIdAsync(subjectClaim.Value, ctx.HttpContext.RequestAborted);
if (user?.SecurityStamp == securityStampClaim.Value)
return;
ctx.SecurityToken = null;
ctx.Ticket = null;
ctx.SkipToNextMiddleware();
}
}
});
Is this how it should be done?

Answer 1

Is this how it should be done?
Technically, yes (you could even use SignInManager.ValidateSecurityStampAsync(principal) to simplify your code a bit).
That said, you should strongly consider avoiding storing the security stamps in your JWT tokens because they are not just "opaque" strings used to determine whether a token or a cookie should be considered as revoked, they are also used as the sole source of entropy by ASP.NET Core Identity to generate 2FA tokens: if you store them as-is in a JWT, they can be easily extracted by a malicious third-party client application and used to predict valid 2FA codes for the logged in user.
This is a known issue, but AFAIK, there's no plan to fix it: https://github.com/aspnet/Identity/issues/626.
If you want to store the security stamps in your access tokens, consider using OpenIddict's default (encrypted) format, which is exactly the same as the one used by ASP.NET Core for its encrypted authentication cookies.