You can diagnose and resolve this ASP.NET error when a user posts a MDriven application page and the server cannot decrypt that page's anti-forgery token; this guidance is for administrators of MDriven web deployments.
What the error means
An anti-forgery token is a value emitted with an ASP.NET page and validated when the browser posts the page back to the server. The token is generated using the server's <machineKey> configuration.
The error occurs when the server receiving the postback cannot decrypt or validate the token that was generated when the page was rendered.
A common example is a load-balanced deployment with two front-end servers:
- The browser opens a page through front-end server A. Server A creates the page and its anti-forgery token using its machine key.
- The user submits the page.
- The load balancer sends the postback to front-end server B.
- Server B uses a different machine key and cannot decrypt the token created by server A.
Check whether the problem is cluster-specific
Use the following observations to narrow down the cause.
| Observation | Likely cause | What to check |
|---|---|---|
| The error occurs only when requests are distributed between multiple front-end servers. | The servers do not share the same explicit machine key configuration. | Compare the <machineKey> configuration on every front-end server.
|
| The error started after a deployment or configuration change on one server. | One server has a different configuration or ASP.NET Web Pages version. | Verify that all front-end servers run the same ASP.NET Web Pages version and configuration. |
| The user opened a page before a configuration change and submits it afterwards. | The page contains a token created with an earlier key or server configuration. | Reload the page to obtain a newly generated token, then repeat the action. |
Configure every front-end server consistently
If the application runs in a web farm or cluster, configure all front-end servers with the same ASP.NET Web Pages version and the same explicit <machineKey> encryption and validation keys.
- Identify every server that can receive browser requests for the application.
- Inspect the application's ASP.NET configuration on each of those servers.
- Configure an explicit
<machineKey>with encryption and validation keys. - Use exactly the same explicit key values on every front-end server.
- Do not use
AutoGeneratefor the machine key in a clustered deployment. - Deploy the matching configuration to all front-end servers.
- Open a new browser page and submit the operation again.
The key values must be treated as security-sensitive configuration. Do not distribute them outside the administrators responsible for the deployment.
Recover from an existing browser page
A page already open in the browser contains the anti-forgery token generated when that page was created. If the server configuration has changed, or if the request is now handled by a server with a different key, that old page can fail on postback.
Ask the user to:
- Return to the affected page.
- Reload the page so that ASP.NET generates a new anti-forgery token.
- Enter any unsaved values again if the reload removed them.
- Submit the operation.
If the error returns after a reload in a web farm, treat the issue as a server-configuration consistency problem and verify every front-end server.
Do not confuse this with login or API tokens
This error concerns the ASP.NET anti-forgery token embedded in a posted web page and the server <machineKey> used to validate it. It is not an error in an OpenID Connect access token, refresh token, OAuth client-credentials flow, or JWT login flow.
For example, an access token used to call an external API is handled separately from the anti-forgery token used when a browser posts a MDriven application page. See Documentation:OpenIdConnect access token and refresh token for OpenID Connect token renewal, HowTos:Oauth2 Client Credentials Grant Flow for server-to-server OAuth, and Documentation:Authenticate with a jwt for JWT authentication.