Auth0 Home Blog Docs

State not received anymore on "implicit grant"


Please fill out the following to the best of your ability. Doing so will help out the troubleshooting process

  • What are you trying to achieve? What is the use case or idea behind it?
    Make our service work again, without changing anything

  • If this is caused by an SDK please mention the SDK along with the specific version number.

  • Is this easily reproducible? If not, please explain.

4 days ago, when we sent the login_url "“” with:

  1. redirect_uri
  2. approval_prompt
  3. scope
  4. client
  5. response_type
  6. state

When you send us to our callback, we received the state, but not anymore (all our services stopped working at once, without touching anything on our side, so we guess that you changed something 4 days ago. ie 9 march)

We had to change our code to not check that anymore (Which is potentially a security issue)

  • If this is related to Lock / any SDK please share the SDK as well as lock initialization code or any code that is relevant.

  • If this is an issue with an API please mention the endpoint you are trying to hit. Relevant code, and or a network trace, is really helpful when debugging such issues.

  • Environment-specific information (Which OS, Language Runtime + Version, Browser etc).


I’m also having something very similar to your problem. I was able to login using my apps, then a few days ago (March 16) authentication worked but I started receiving an error {error: "invalid_token", errorDescription: "statedoes not match."}. Tracing through the app, indeed state was not being passed through.

I too can change code that will bypass this but obviously this is not a good solution.


@michael.bitard you mention that you performed a request to /login, but that is not correct. The expected endpoint to start an OIDC/OAuth 2.0 authentication/authorization request would be /authorize. If you’re calling /login directly you need to change this.

@cody.mcmichael if you’re also starting the transaction at /login and this is the reason you don’t have a valid state then you should also update your logic to not call that endpoint directly. If this is not the reason then you’ll need to provide additional information about how the request is started.


@jmangelo Thanks for your answer!

I’ll try that soon. In the meantime, can you tell me why this still works when I call /login? It should not, right?
I’m also curious to know what changed on auth0 side to stop sending back the state


I believe it works when Legacy Lock API toggle is enabled so that will likely change soon due to the April 1st migration. I don’t think the /login endpoint was ever documented as part of the Authentication API (; it exists and is externally visible due to /authorize also redirecting to it for some scenarios, but to my knowledge this was meant to be an internal endpoint so changes in behavior in that endpoint are okay given the assumption (which in reality does not hold as we’ve seen) that this would only have internal consumers.


Thanks for everything, it works like a charm!


Thanks for the reply @jmangelo. Some background, this is an external app embedded into a site that we own via an iframe. It was working until last friday, there were no changes made. This is our basic login setup.

renew () {
      const _self = this;
      }, function (err, result) {
          if (err) {
              alert(`Could not get a new token using silent authentication (${err.error}). Redirecting to login page...`);
              // _self.auth0.authorize();  // This works...
              const url = _self.auth0.client.buildAuthorizeUrl({
                clientID: 'APP_CONFIG.authClientId',
                redirectUri: APP_CONFIG.authCallbackUrl,
    , '_self')
          } else {

  login() {

We check if we already have an SSO session if we do, everything works great we have a state param come back and it logs us in locally. However, since we are in an iframe and because we do social login as well I have to remove the app from iframe and call it from the parent window because google and facebook do not allow an iframe to authenticate with them… This is where the buildAuthrorizeUrl comes in. Seems to work perfectly.

When a user has logged in via the hosted login pages they are redirected back to our callback route on our site. It uses the methods.

handleAuthentication() {
    this.auth0.parseHash((err, authResult) => {
      const _this = this;
      if (authResult && authResult.accessToken && authResult.idToken) {

 setSession(authResult, username) {
    if (authResult && authResult.accessToken && authResult.idToken) {
      // Store user profile information
      this.fetchUserProfile(authResult, username);
      // Set the time that the access token will expire at
      let expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
      localStorage.setItem(ACCESS_TOKEN, authResult.accessToken);
      localStorage.setItem(ID_TOKEN, authResult.idToken);
      localStorage.setItem(EXPIRES_AT, expiresAt);

      // after authentication this returns the user back back to the page they were on and then launches the app inside a modal/iframe again in a now logged in state
      const entrance = localStorage.getItem(GIVING_ENTRANCE) || '/giving/';
      const newUrl = entrance + '#giving-app';
      return, '_self');

The user actually becomes logged in globally, however, in the parseHash method it will fail because “state does not match.”


The above code does not specify a state parameter so the authorization URL created will not include one; the latest versions of client SDK’s for web application require the presence of a state parameter and when used to start the transaction always generate a state. Given you’re using a utility method to create the authorization URL the library will not do this automatically.

You can continue to use that method and provide the state yourself, but then when parsing/validating the response you would also have to provide the same state value when calling parseHash (see


I’m having a similar issue as well.

I pass a URL parameter redirect_uri to the /authorize endpoint. The param value is URI encoded and includes it’s own parameter, login_type. I need this value on the customized hosted login page. Something stopped working 2 days ago. I noticed that /authorize is not redirecting to /login, and the redirect_uri parameter is not being passed to /login.

I’m not certain, but I don’t think /authorize used to redirect to /login, and I believe this is the issue.

Can someone please confirm? My login screen is now broken.


You should probably open this as a new topic (if you haven’t done so already) and also include an HTTP trace (HAR) that illustrates the situation.


That was the issue! I guess tha changed recently because it was working and it just stopped! Adding that in fixed everything. Thanks for the help!


This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.