dotnet/aspnetcore · error · AntiforgeryValidationException
The provided antiforgery token was meant for user "{0}", but
Error message
The provided antiforgery token was meant for user "{0}", but the current user is "{1}". What it means
Thrown during TryValidateTokenSet when the Username baked into the request token does not match the current authenticated user's name. The antiforgery system binds each request token to the identity of the user for whom it was generated; if a different user submits it, validation fails. Results in AntiforgeryValidationException. The message is produced by FormatAntiforgeryToken_UsernameMismatch at DefaultAntiforgeryTokenGenerator.cs:173.
Source
Thrown at src/Antiforgery/src/Internal/DefaultAntiforgery.cs:200
// Extract cookie & request tokens
AntiforgeryToken deserializedCookieToken;
AntiforgeryToken deserializedRequestToken;
DeserializeTokens(
httpContext,
antiforgeryTokenSet,
out deserializedCookieToken,
out deserializedRequestToken);
// Validate
if (!_tokenGenerator.TryValidateTokenSet(
httpContext,
deserializedCookieToken,
deserializedRequestToken,
out var message))
{
throw new AntiforgeryValidationException(message);
}
}
/// <inheritdoc />
public void SetCookieTokenAndHeader(HttpContext httpContext)
{
ArgumentNullException.ThrowIfNull(httpContext);
CheckSSLConfig(httpContext);
var antiforgeryFeature = GetCookieTokens(httpContext);
if (!antiforgeryFeature.HaveStoredNewCookieToken && antiforgeryFeature.NewCookieToken != null)
{
if (antiforgeryFeature.NewCookieTokenString == null)
{
antiforgeryFeature.NewCookieTokenString =
_tokenSerializer.Serialize(antiforgeryFeature.NewCookieToken);
}View on GitHub (pinned to 294cab2f9b)
Solutions
- After login/logout, redirect to a fresh page so new antiforgery tokens are generated for the new identity.
- Ensure NameClaimType is set consistently in authentication configuration so IIdentity.Name resolves to a stable, unique identifier.
- Add Cache-Control: no-store to pages containing forms so the browser doesn't reuse a previous user's tokens.
- If using custom authentication, verify the ClaimsIdentity.Name matches the value used at token generation time.
Example fix
// before — stale page submitted after switching users
// (user A's form submitted after logout/login as user B)
// after — invalidate and regenerate tokens on auth change
await _signInManager.SignOutAsync();
await _antiforgery.GetAndStoreTokens(HttpContext); // fresh tokens for next identity
return RedirectToPage("/Login"); Defensive patterns
Strategy: try-catch
Try / catch
try
{
await _antiforgery.ValidateRequestAsync(HttpContext);
}
catch (AntiforgeryValidationException ex)
{
_logger.LogWarning("Token user mismatch: {Msg}", ex.Message);
return Challenge(); // force re-authentication
} Prevention
- Redirect to a fresh page after login/logout to regenerate tokens.
- Set Cache-Control: no-store on pages with forms to prevent cross-user token reuse.
- Keep NameClaimType consistent across authentication scheme changes.
When it happens
Trigger: An authenticated user 'A' loads a form (request token bound to 'A'), then user 'B' (or a logged-out session) submits that form. Detected at line 169 when !comparer.Equals(requestToken.Username, currentUsername) and the current user IS authenticated but under a different name.
Common situations: Two users sharing a browser without logging out; a cached page or back-button submission after login as a different user; concurrent sessions where a tab's tokens are cross-submitted; custom authentication that changes the IIdentity.Name claim after the token was minted.
Related errors
- Validation of the provided antiforgery token failed. The coo
- The antiforgery cookie token and request token do not match.
- The provided antiforgery token was meant for a different cla
- The provided antiforgery token was meant for an authenticate
- The required antiforgery cookie "{0}" is not present.
AI-assisted analysis of dotnet/aspnetcore@294cab2f9b (2026-08-06).
Data as JSON: /api/errors/16410e2919bfa6ed.
Report an issue: GitHub.