Tenant log `details.qs.state` field doesn't match with the `state` sent in /authorize request

Last Updated: Feb 20, 2026

Overview

We want to know why in a Failed Login event log the “state” attribute is not the same as the one sent the authorization routine.

Cause

n/a

Solution

To answer this question, I need to start with the 2 types of `state` parameter/attribute used in the Auth0 login flow.
1) The `state` used in OAuth2 authorization flow
https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow
https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1
This `state` is generated by the application and sent to the `/authorize` endpoint of Auth0. When Auth0 redirects the user back to the application's callback URL, the `state` value must be an exact match to the one sent by the application.
This is the `state` value sent in the authorization endpoint by the application.

2) The `state` used by Auth0 during the login/signup flow
A login/signup flow involves multiple API calls to Auth0, to maintain the state of the user in the login/signup flow (e.g. authenticated, executing rules, MFA, and etc), the `state` parameter is used and present in almost every Auth0 API calls.
For example, in the request to `GET /authorize/resume` endpoint, there is a `state` parameter:

https://TENANT_NAME.auth0.com/authorize/resume?state=lWdp_kWJIq5VWG8K8n7jM2rlt7jI0bY8

The `state` parameter value here is the `state` field recorded in the tenant log as `details.qs.state`.