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

Knowledge Articles
, , ,
1

Problem statement

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

Solution

There are two types of state parameter/attribute used in the Auth0 login flow.

  1. The state used in OAuth2 authorization flow
  • Authorization Code Flow
  • RFC 6749 - The OAuth 2.0 Authorization Framework
    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.
  1. The state used by Auth0 during the login/signup flow
    A login/signup flow involves multiple API calls to Auth0 for maintaining the state of the user in the login/signup flow (e.g. authenticated, executing rules, MFA, etc.). The state parameter is used and present in almost every Auth0 API call.
    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.