Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid token - state does not match #655

Closed
jeiman opened this issue Feb 7, 2018 · 88 comments
Closed

Invalid token - state does not match #655

jeiman opened this issue Feb 7, 2018 · 88 comments

Comments

@jeiman
Copy link

jeiman commented Feb 7, 2018

So for some reason I can't seem to authenticate users on certain computers/laptops that has the same browser versions.

auth.js

export var webAuth = new auth0.WebAuth({
    domain: 'xxx.auth0.com',
    clientID: 'xxx',
    responseType: 'token id_token',
    audience: 'https://xxx.auth0.com/userinfo',
    redirectUri: 'http://localhost:3000'
  })

Login.vue

if (window.location.hash) {
        webAuth.parseHash({ hash: window.location.hash }, (err, authResult) => {
          if (err) {
            return console.log('parseHash error', err)
          }
          if (authResult) {
            webAuth.client.userInfo(authResult.accessToken, function(err, user) {
              if (err) {
                console.log('err accessToken', err)
              }
              localStorage.setItem('profile', JSON.stringify(user))
              localStorage.setItem('id_token', authResult.idToken)
              window.location = '/state'
            })
          }
        })
      }

Picture:

error

Other details:

Auth0 version:
NPM - 8.12.2
ScriptJS - 8.12.2

Browser: Chrome Version 64.0.3282.140 (Official Build) (64-bit)
O.S: Windows 10

The issue is not happening on my laptop (which is running on the the Browser version mentioned above), but it is happening on other laptops (same browser version).

Not too sure what else to try here. Been looking at the forums, nothing is working out.

Would love some insights on this.
Thank you.

@luisrudge
Copy link
Contributor

Can you reproduce this in any way? Your code looks fine, but we need to find a way to reproduce the issue.

@VinSpee
Copy link

VinSpee commented Feb 8, 2018

I'm having the same issue, happens of everly login, but on refresh, i can get profiles without issue.

Here's my auth component:

import Auth0Lock from 'auth0-lock';
import { withRouter } from 'react-router-dom';
import { Component } from 'react';
import PropTypes from 'prop-types';

class AuthProvider extends Component {
  static propTypes = {
    history: PropTypes.object.isRequired, // eslint-disable-line
    children: PropTypes.func.isRequired,
  };

  constructor(props) {
    super(props);
    this.state = {
      profile: null,
    };

    this.history = props.history;
    this.lock = new Auth0Lock(AUTH_CONFIG.clientId, AUTH_CONFIG.domain, {
      autoclose: true,
      auth: {
        redirectUrl: AUTH_CONFIG.callbackURL,
        responseType: 'token id_token',
        audience: `https://${AUTH_CONFIG.domain}/userinfo`,
        params: {
          scope: 'openid profile',
        },
      },
    });
    this.handleAuthentication();
    // binds functions to keep this context
    this.getProfile = this.getProfile.bind(this);
  }

  componentWillMount() {
    const { userProfile, getProfile } = this;
    if (!userProfile) {
      getProfile((err, profile) => {
        this.setState(state => ({
          ...state,
          profile,
        }));
      });
    } else {
      this.setState(state => ({
        ...state,
        profile: userProfile,
      }));
    }
  }

  getProfile(cb) {
    const accessToken = this.getAccessToken();
    if (accessToken) {
      this.lock.getUserInfo(accessToken, (err, profile) => {
        if (profile) {
          this.userProfile = profile;
        }
        cb(err, profile);
      });
    }
  }

  getAccessToken = () => {
    const accessToken = localStorage.getItem('accessToken');
    if (!accessToken) {
      console.error('No access token found');
    }
    return accessToken;
  }

  setSession(authResult) {
    if (authResult && authResult.accessToken && authResult.idToken) {
      // Set the time that the access token will expire at
      const expiresAt = JSON.stringify((authResult.expiresIn * 1000) + new Date().getTime());
      localStorage.setItem('accessToken', authResult.accessToken);
      localStorage.setItem('idToken', authResult.idToken);
      localStorage.setItem('expiresAt', expiresAt);
      // navigate to the home route
      this.history.replace('/');
    }
  }

  handleAuthentication() {
    // Add a callback for Lock's `authenticated` event
    this.lock.on('authenticated', this.setSession.bind(this));
    // Add a callback for Lock's `authorization_error` event
    this.lock.on('authorization_error', (err) => {
      console.log(err); // eslint-disable-line no-console
      this.props.history.replace('/');
    });
  }

  isAuthenticated = () => {
    // Check whether the current time is past the
    // access token's expiry time
    const expiresAt = JSON.parse(localStorage.getItem('expiresAt'));
    return new Date().getTime() < expiresAt;
  }

  login = () => {
    // Call the show method to display the widget.
    this.lock.show();
  }

  logout = () => {
    // Clear access token and ID token from local storage
    localStorage.removeItem('accessToken');
    localStorage.removeItem('idToken');
    localStorage.removeItem('expiresAt');
    // navigate to the home route
    this.props.history.replace('/');
    this.setState(() => ({
      profile: null,
    }));
  }

  render() {
    const { children } = this.props;
    return children({
      profile: this.state.profile,
      authInstance: this.lock,
      login: this.login,
      logout: this.logout,
      authenticated: this.isAuthenticated(),
    });
  }
}

export default withRouter(AuthProvider);

and login:

import React from 'react';
import Button from 'components/button';
import Auth from 'components/auth';
import { withRouter } from 'react-router-dom';

const LoginPage = () => (
  <div>
    <Auth>
      {({
        login,
      }) => (
        <button
          onClick={login}
          className="
            Bd(n)
            Bg(n)
          "
        >
          <Button>
            Log In
          </Button>
        </button>
      )}
    </Auth>
  </div>
);

export default withRouter(LoginPage);

@luisrudge
Copy link
Contributor

thanks @VinSpee can you build a simple repro so we can isolate the issue?

@nicosabena
Copy link
Member

nicosabena commented Feb 9, 2018

I've seen this happening sometimes if the authorize request is made from a different origin than the callback URL. E.g. you navigate to "http://myapp.com", and instead of redirecting first to "https://myapp.com", it goes directly to "https://yourtenant.auth0.com/authorize?...&redirect_uri=https://myapp.com" (notice the difference between "http://" and "https://").
Since Auth0.js stores the state in local storage before redirecting to Auth0 for later verification, you need to ensure that the origin where the authorize request originates is the same as the callback URL.

@luisrudge for easier troubleshooting, I might be a good idea to log in the console a little more data, like the state that came in the callback, and what was there in localStorage (no match?). Even a list of states present in LocalStorage might help.

Or maybe just handle one possible state storage slot instead (i.e. not including the state value as part of the key for local storage)?

@luisrudge
Copy link
Contributor

@nicosabena that's a nice idea, but always logging that would not be good. Maybe we should have a debug mode (manually set localStorage or ?debug in the url or something).

@VinSpee
Copy link

VinSpee commented Feb 11, 2018

Here's a minimal repro:

code: https://github.com/VinSpee/auth0-debug
live: https://recondite-lake.surge.sh/login

@luisrudge
Copy link
Contributor

@VinSpee are you having this issue with google apps only?

@luisrudge
Copy link
Contributor

I tested your app a few times and I always get the profile back. Do I have to do something different to see the error?
gh-state

@VinSpee
Copy link

VinSpee commented Feb 15, 2018

@luisrudge to be more clear: I am able to get the profile, but always get the console error:

Object { error: "invalid_token", errorDescription: "state does not match." }

@luisrudge
Copy link
Contributor

@VinSpee ah, right. Sorry I missed that! Does this happen only with google?

@VinSpee
Copy link

VinSpee commented Feb 15, 2018

i've only tried in w/ google auth, I'll try with another provider

@VinSpee
Copy link

VinSpee commented Feb 15, 2018

I just tried it w/ GitHub as the provider and got the same error:

Object { error: "invalid_token", errorDescription: "state does not match." }

@luisrudge
Copy link
Contributor

@VinSpee your code is running twice:

image

Every time you use the <Auth> component, you're creating a new instance of Lock, and this is messing up the state handler.

So, it runs twice because you use the component both in the index route and in child routes:
https://github.com/VinSpee/auth0-debug/blob/master/src/index.js#L20
https://github.com/VinSpee/auth0-debug/blob/master/src/Login.js#L6

We have a react sample here if you want to take a look.

You're also shipping two versions of react, because auth0-lock is using react@15, so you need to add this to your package.json file:

  "resolutions": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0"
  }

@staab
Copy link

staab commented Mar 30, 2018

I've been having the same problem, and I've found a workaround which I'll describe below just because I saw a lot of google results for this error, which seemed to be caused by all kinds of different things. However, I did find the proper solution, which is to use WebAuth.logout rather than buildAuthorizeUrl:

export function logout() {
  webAuth.logout({
    clientID: process.env.REACT_APP_AUTH0_CLIENT_ID,
    responseType: 'token',
    redirectUri: window.location.origin,
  })
}

My problem was that I generated a logout url using buildAuthorizeUrl with auth0-js v9.4.2. When I do this though, I redirect to the url manually, so the state doesn't get set by auth0:

export function logout() {
  const state = randomId()

  // Save state to localstorage for Auth0
  // https://auth0.com/docs/protocols/oauth2/oauth-state
  localStorage.setItem('auth0-authorize', state)

  const domain = process.env.REACT_APP_AUTH0_DOMAIN
  const clientId = process.env.REACT_APP_AUTH0_CLIENT_ID
  const returnTo = webAuth.client.buildAuthorizeUrl({
    clientID: clientId,
    responseType: 'token',
    redirectUri: window.location.origin,
    state,
  })

  const params = stringify({returnTo, client_id: clientId})

  window.location.assign(`https://${domain}/v2/logout?${params}`)
}

When someone hits the site and isn't authenticated, I redirect them to auth0 with authorize. This sets the state in a different place in localstorage (seems to be a randomly generated string). To handle both my custom logout state and the built-in logout state, I'm providing an options parameter to parseHash with the state set only if my custom key is set (being sure to clear my custom one when I use it to avoid always rejecting one set by auth0). Here's my code:

function checkAuthResult(err, authResult) {
  if (err) {
    // If we tried to log them in automatically, redirect to auth0
    webAuth.authorize()
  } else if (!authResult) {
    // Try logging them automatically first
    // https://auth0.com/docs/libraries/auth0js/v8#using-checksession-to-acquire-new-tokens
    webAuth.checkSession({}, checkAuthResult)
  } else if (authResult.accessToken) {
    resolve(authResult)
  }
}

// If we log out, auth0 doesn't set the state properly, so we have to do it manually.
// We can't do it every time though, because when they're trying to log from a url
// not generated by buildAuthorizeUrl, we need to let the default behavior work.
const state = localStorage.getItem('auth0-authorize')
const params = state ? {state} : {}

// Make sure to clear our custom state key
localStorage.setItem('auth0-authorize', '')

webAuth.parseHash(params, checkAuthResult)

@luisrudge
Copy link
Contributor

@staab not sure I understand: why are you setting a state when doing a log out?

@staab
Copy link

staab commented Apr 2, 2018

@luisrudge because I'm redirecting to the login page for auth0, which doubles as our landing page for folks who aren't signed in (I'm not using auth0-lock, and our software is login-only). As I understand it, there's no way to go to that page and have it successfully log someone in if state isn't set. Also, as far as I can tell, this is exactly what the logout() method was created for.

@luisrudge
Copy link
Contributor

@staab

to log in with the universal login page, you do:

var options = {}; //anything you want, state is not required but you can use your own state here if you want
webAuth.authorize(options);

to log out from auth0, you do:

var options = {}; //again, no state required
webAuth.logout(options);

I mean, you're free to call the /v2/logout endpoint by yourself (although I don't see the point in doing it manually), but there's no need to send a state to the logout endpoint.

@staab
Copy link

staab commented Apr 2, 2018

@luisrudge that's what I'm doing now (see the top of my original comment). I was mostly including my manual logout solution for posterity, since I hadn't seen the mistake I had made anywhere else after some googling.

After some more digging, it turns out that it's not logout that's passing state, I'm redirecting back to my app after logging out, then calling authorize, which passes state. I had missed that step. So you're right, logout doesn't use state. To fix this, I'll see if I can pass an authorization url to redirectUri.

@staab
Copy link

staab commented Apr 2, 2018

Ok, so I tried passing a redirectUri built using buildAuthorizeUrl with a custom managed state to get the app > logout > hosted login page redirect flow I want, but logout always returns a 302 with Location: myappdomain rather than the redirect_uri that gets passed via query parameters. I think this is what threw me off originally; is there a way to get logout to set the Location header to mydomain.auth0.com/login?... with a valid state/audience/etc?

@luisrudge
Copy link
Contributor

logout expects a returnTo param, not redirectUri.

logout({
  returnTo: 'https://myapp.com/login'
})

@luisrudge
Copy link
Contributor

@staab
Copy link

staab commented Apr 2, 2018

Ah ok thanks, that did the trick.

Now that my credibility has been destroyed by not being able to read the documentation properly, is redirecting to the login page straight from the logout endpoint a common use case or am I an outlier? If it's common, it would be really nice for logout/buildAuthorizeUrl to handle setting state the same way authorize does.

@luisrudge
Copy link
Contributor

from logout directly to the universal hosted login page is the first time I saw it 😝
The best way to do what you want is:

your app > click logout > webauth.logout({returnTo: 'https://myapp.com/login'}) > https://myapp.com/login > webAuth.authorize() > universal login page.

So, you create a step in between the logout and redirecting to the universal login page and, in this new step, you call authorize(). Then auth0.js will handle all the state and everything should work!

@staab
Copy link

staab commented Apr 3, 2018

Fair enough! I had it set up the way you described before, but I figured saving a redirect to my tool would be the best use of our resources and user experience. Not a big deal in any event though. Thanks for the help!

@bramski
Copy link

bramski commented Apr 12, 2018

I have come upon this error due to failure to JSON.stringify my state parameters before sending them to auth0 for authorize. Rather annoying error for a simple mistake. Auth0 library should really verify that the state is a "string" as objects don't work so well.

@luisrudge
Copy link
Contributor

@bramski what was the error? we want to support objects so you can restore an app state if you need to

@bramski
Copy link

bramski commented Apr 12, 2018

@luisrudge Here's the problem:
screen shot 2018-04-11 at 5 20 50 pm

@luisrudge
Copy link
Contributor

Ah, yeah. I misread your comment! Yes, the state param has to be a string. But you can stringify your object and use that if you want.
This is documented here and here

@maneshom
Copy link

same error as @VinSpee .But it works fine with google chrome .In mozilla,Error showing only in the first time of login and after the cookie added it works.

@KevinKons
Copy link

do you mean the source code?

@luisrudge
Copy link
Contributor

I mean try to isolate the authentication code and make it fail so I can take a look or give me instructions on how to login in your application

@KevinKons
Copy link

I can give you instructions on how to login, I'll send you an email in luis@luisrudge.net with credentials. Ok?

@luisrudge
Copy link
Contributor

before doing that, please send a HAR file with all the authentication requests to luis.rudge@auth0.com

@KevinKons
Copy link

ok

@longfellowone
Copy link

Also having this issue, Firefox 67 on linux. Using the ReactJS demo app, untouched

@therockstorm
Copy link

therockstorm commented Mar 29, 2019

About Firefox: this is a firefox/sample issue and has nothing to do with the SDK itself. It's exactly what @fourthmeal70 said.. When you click refresh page in firefox, it seems to use the previous URL for some reason, causing the page to try to parseHash again, which will break. I'll redirect the issue to our samples team.

This is still happening in the sample app, @luisrudge. You mentioned redirecting it to that team, could you provide a link so I can follow that issue?

@trusktr
Copy link

trusktr commented Apr 30, 2019

Callback URL set to a different domain. E.g. your app started at the http://myapp.com and the callback is set to https://myapp.com

Can a trailing slash make a difference? f.e. http://localhost:9080 vs http://localhost:9080/?

And how does auth0 detect which location the app started at?

@luisrudge
Copy link
Contributor

luisrudge commented Apr 30, 2019 via email

@trusktr
Copy link

trusktr commented Apr 30, 2019

@luisrudge Not sure I understand correctly. So for example, if we're on http://localhost:1234/foo/ then either redirectUrl or returnTo (or both?) need to also be exactly http://localhost:1234/foo/?

@trusktr
Copy link

trusktr commented Apr 30, 2019

In all sincerity, this `state` does not match. message is not at all helpful. The above comments mention some "possible causes", but it's still not clear. It'd be nice if there was a clear reason (in the error output) stating what the specific problem is.

@trusktr
Copy link

trusktr commented Apr 30, 2019

I think I'm using auth0-lock like normal. I've constructed it, and given it some options. Then when I try to log in, I call lock.resumeAuth once I have the hash, then I get the above error.

After stepping through auth0 code, I see that StorageHandler.setItem is being called twice with the same value. Eventually, WebAuth.parseHash is called internally, and this seems related to the above problem of

app is causing parseHash to be called twice

But, I'm not calling parseHash, I'm just using Auth0's Lock with some options passed to it, and letting it handle the rest.

What can be causing the Lock to indirectly cause that parseHash-called-twice (or something-else-twice problem)?

@trusktr
Copy link

trusktr commented Apr 30, 2019

Yep, I can confirm by stepping through auth0-js code (used by auth0-lock) that parseHash is called twice, which ultimately calls WebAuth.validateAuthenticationResponse twice, and that second call outputs that cryptic error message.

@trusktr
Copy link

trusktr commented Apr 30, 2019

CRAAAAAP.

So I'm using lock.resumeAuth, but I did not set auth0-lock Lock option autoParseHash to false, so this caused parseHash to be called twice. I solved that issue by setting autoParseHash to false.

Note, in the autoParseHash or resumeAuth documentation, there is not a single mention of this cryptic error!!!!

However, now that I've solved that problem, and I can verify that parseHash is not being called twice, now something else is causing the same error. I have a feeling now I'm encountering this problem (double whammy):

you need to ensure that the origin where the authorize request originates is the same as the callback URL


It'd be very nice for the Auth0 team to take this problem seriously and make it more clear, both in the documentation, and by providing contextual error messages rather than `state` does not match..

Now I'll continue to step through auth0 code in Chrome devtools until I find the second source of the error, which as paying customer wish I didn't have to do.

If anything, a prorated refund of the wasted time would be very welcome, and would make all frustrations go away, because I need to be working on the business product where I work, instead of wasting resources.

@luisrudge
Copy link
Contributor

@luisrudge Not sure I understand correctly. So for example, if we're on http://localhost:1234/foo/ then either redirectUrl or returnTo (or both?) need to also be exactly http://localhost:1234/foo/?

If you want to redirect to http://localhost:1234/foo/, then it needs to match that url exactly (http://localhost:1234/foo is not the same as http://localhost:1234/foo/ in this case).

In all sincerity, this state does not match. message is not at all helpful. The above comments mention some "possible causes", but it's still not clear. It'd be nice if there was a clear reason (in the error output) stating what the specific problem is.

I agree, but auth0-js doesn't have enough information on why the state didn't match. We can add the possible causes that we mentioned in this thread, but we can't pin point exactly what happened because there's simply not enough info. From Auth0-js's perspective, all we know is that we were expecting a string to be present in a cookie, but the string is not there.

CRAAAAAP.

So I'm using lock.resumeAuth, but I did not set auth0-lock Lock option autoParseHash to false, so this caused parseHash to be called twice. I solved that issue by setting autoParseHash to false.

Note, in the autoParseHash or resumeAuth documentation, there is not a single mention of this cryptic error!!!!

I opened a PR to make it clearer that you can only use resumeAuth when you use autoParseHash:false: auth0/docs#7569

It'd be very nice for the Auth0 team to take this problem seriously and make it more clear, both in the documentation, and by providing contextual error messages rather than state does not match..

See me previous message about not having enough context to pinpoint the issue

Now I'll continue to step through auth0 code in Chrome devtools until I find the second source of the error, which as paying customer wish I didn't have to do.

Feel free to ping our amazing support team at http://support.auth0.com to get some help figuring out your issue.

If anything, a prorated refund of the wasted time would be very welcome, and would make all frustrations go away, because I need to be working on the business product where I work, instead of wasting resources.

I can't do that, but feel free to ping someone at http://support.auth0.com with your frustrations to see what they can do.

@trusktr
Copy link

trusktr commented Apr 30, 2019

Thanks, I left a comment in the PR, I do think mentioning the exact `state` does not match message would be helpful.

Alright, I've found that inside of WebAuth.prototype.validateAuthenticationResponse, options.state is undefined, which causes the error.

Any idea why options.state inside WebAuth.prototype.validateAuthenticationResponse can be undefined?

@trusktr
Copy link

trusktr commented Apr 30, 2019

Docs say:

Auth0.js, when used in single-page applications, handles the state generation and validation automatically if not specified.

I'm not supplying a state value, so shouldn't it be automatically generated?

@luisrudge
Copy link
Contributor

@trusktr it is, unless you're using IE10 (no support to crypto)

@trusktr
Copy link

trusktr commented Apr 30, 2019

I'm in Electron with Chrome 66.0.3359.181.

@trusktr
Copy link

trusktr commented Apr 30, 2019

Looks like the Auth0Lock constructor is calling the Auth0APIClient constructor, and the options that it passes into that has state as undefined. Eventually, WebAuth.prototype.validateAuthenticationResponse reads the undefined value from Auth0APIClient.authOpt.state, which is undefined.

@luisrudge
Copy link
Contributor

FYI, Auth0.js and Lock do not support Electron. More context here. We have some guidance on how to build electron apps with Auth0 here: https://auth0.com/blog/securing-electron-applications-with-openid-connect-and-oauth-2/

@trusktr
Copy link

trusktr commented Apr 30, 2019

Still, any idea why state is undefined?

@trusktr
Copy link

trusktr commented Apr 30, 2019

Here's another question: if we manually supply a state value, then it won't be undefined. What sort of value should we supply there? EDIT: Looks like TransactionManager sets a random value. So looks like I can just use a hard-coded (or from env) random string.

@trusktr
Copy link

trusktr commented Apr 30, 2019

Okay, even if I supply a hard-coded value for auth.params.state in Auth0Lock options, I still get the same error, in WebAuth.prototype.validateAuthenticationResponse I still see options.state is undefined.

Note, every time I start the app, I've cleared all cache (deleted the Chrome profile and Electron folder). So it's completely clean. There's nothing in local storage, etc.

@trusktr
Copy link

trusktr commented Apr 30, 2019

I see TransactionManager.prototype.process is not called before the error happens, and the default state handling is in that method.

I see WebAuth.prototype.parseHash is called before that default handling.

Am I calling lock.resumeAuth too early? Do I need to wait for something before calling it in my entry point? Is there another way to pass a state value so it won't be undefined?

@trusktr
Copy link

trusktr commented May 1, 2019

If autoParseHash is set to false, is there anything we need to do besides call lock.resumeAuth with the hash?

@luisrudge
Copy link
Contributor

@trusktr do you want to publish a repro somewhere that I can take a look? I feel like you're trying to dig into the internals too much and this feature is working as expected, so it should be an integration issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests