Nonce does not match [8.2.0]

[murtyjones]

I'm using parseHash to parse the access_token returned after logging a user in and occasionally receiving an error about the nonce not matching.

this.auth0 = new auth0.WebAuth({
      clientID: clientId,
      domain: domain,
      leeway: 60 // 1 minute leeway
    });

...

parseInfo(hash) {
    return new BluebirdPromise((resolve, reject) => {
      return this.parseHash(hash, (err, authResult) => {
        if (err) {
          return console.log(err);
        }
        const {accessToken, idToken} = authResult;

        return this.auth0.client.userInfo(accessToken, (err, profile) => {
          return resolve({profile, idToken});
        });
      });
    });
  }

...

_socialLogin(connection) {
    //redirects the call to auth0 instance
    const loginParams = {
      connection: connection,
      responseType: 'token id_token',
      redirectUri: `${Config.clientUrl}/auth/callback`,
      scope: LOGIN_TOKEN_SCOPE
    };

    this.auth0.authorize(loginParams);
  }

I'm passing window.location.hash to the parseInfo function. Is there something I'm missing based on the above configuration that might sometimes return a nonce match error?

[iongion]

+1 Same problem - no other info, just a Nonce does not match ...

[hzalaz]

@murtyjones by any chance are you in IE? and what version?

[murtyjones]

Auth0 version 8.2.0; issue has been observed in Chrome 56+ but not tested in IE.

I seem to have worked around it by passing the nonce explicitly to parseHash.

parseInfo(hash, nonce) {
  return new BluebirdPromise((resolve, reject) => {
    return this.parseHash({hash, nonce}, (err, authResult) => {
      if (err) {
        return console.log(err);
      }
      const {accessToken, idToken} = authResult;

      return this.getUserInfo(accessToken, (err, profile) => {
        return resolve({profile, idToken});
      });
    });
  });
}

...
const nonce = decode(queryString.parse(window.location.hash).id_token).nonce;
const hash = window.location.hash;
return resolve(parseInfo(hash, nonce));

[hzalaz]

@murtyjones are you generating the nonce yourself?

[murtyjones]

Nope, receiving it as part of the id_token in the callback after login.

[hzalaz]

@murtyjones can you build up a small sample to see it. I fail to see the issue and still works from me so it should be a subtle detail we are missing. (you can use one of our quickstarts as template).

In theory the nonce handling should be done by auth0.js so you should not be parsing and passing the nonce unless you are building it yourself.

[seawatts]

I'm also seeing this issue in the ember-simple-auth-auth0 addon

[murtyjones]

@hzalaz Not sure I have much to add by building a new example, as the code previously posted is basically it with respect to the auth0 API's usage.

[BLevinger]

I had this issue occur due to an '=' character being appended to my base64 encoded state data. Check to make sure your state (if you specify it) doesn't include an '=', the auth0 library will not decode %3D and subsequently fails to find the appropriate transaction to verify the nonce

[hzalaz]

@DigitalFoundry-Brandon can you submit an issue describing it please? We'll fix it in the next version

[BLevinger]

@hzalaz Issue logged as #377

[hzalaz]

Thanks a lot @DigitalFoundry-Brandon

[davidascher]

FYI: in my case, the problem was that I was calling parseHash and not specifying options (as the samples e.g. https://github.com/auth0-samples/auth0-react-samples/blob/master/01-Login/src/Auth/Auth.js#L29 do. Once I changed:

    this.auth0.parseHash((err, authResult) => {

to

    this.auth0.parseHash(window.location.hash, (err, authResult) => {

the nonce complaint went away.

[tdekoekkoek]

Thanks @davidascher, that fixed my problem as well. Strange though as the sample Angular 2 app on Auth0 site did not include the window.location.hash.

[mmazzarolo]

Thanks @davidascher, that fixed my issue too.

[luisrudge]

That's very weird, indeed.

auth0.js/src/web-auth/index.js

Line 140 in 84f0dd5

var hashStr = options.hash === undefined ? _window.location.hash : options.hash;

This line will use window.location.hash if you don't provide a hash. It should work either way. I'll take a look on this on Monday.

[luisrudge]

@mmazzarolo I just tested with our test page, and everything works. Including calling parseHash without any options:
https://github.com/auth0/auth0.js/blob/master/example/index.html#L216

Do you think you help us by creating a simple repro project so we can find this issue?

[mmazzarolo]

Yup, I'll probably release soon the project repo (it's private while being a wip)

[fhur]

I was also experiencing this bug and to my surprise the window.location.hash trick did fix it.

[mmazzarolo]

I'm still working on it, sorry.
I'll drop an hint though: may it is be related to the fact that I'm calling parseHash from a different application (with even a different domain) than the one that called authorize?

[tiny-dancer]

Ran into this and believe i may have found the cause (however didn't dig for the solution). Appears when passing in window.location.hash it skips the token verification, thus removing the error.

---

this.auth0.parseHash((err, authResult) => {

leads to:

if (parsedQs.id_token && options._idTokenVerification) {
// where
options._idTokenVerification = true

---

this.auth0.parseHash(window.location.hash, (err, authResult) => {

leads to:

if (parsedQs.id_token && options._idTokenVerification) {
// where
options._idTokenVerification = undefined

[eicca]

We're using hosted lock and we're experiencing the same issue, but only sometimes.

As @tiny-dancer already mentioned: the "fix" with using this.auth0.parseHash(window.location.hash, (err, authResult) => { works because it simply disables the token verification. Function parseHash accepts either callback or options object and a callback. The proper way to pass the hash would be this.auth0.parseHash({hash: window.location.hash}, (err, authResult) => { and it behaves identically to just this.auth0.parseHash((err, authResult) => {.

We noticed that sometimes function authorize will not persist generated nonce. And it leads later (after redirecting to the callback page) to the Nonce does not match error. We failed to understand why exactly it's happening.

Most of the times it's possible to reproduce the issue by using firefox in incognito mode.

In general, it looks like localStorage behaves strangely from time to time. It might be that authorize tries to use localStorage before it's available.

[wpitallo]

I am getting the same error, how can this still be an issue. We cannot use a product so important for login that works sometime and sometimes does not. Also why has this not been urgently resolved by the Auth0 team?

[luisrudge]

@wpitallo do you have more info on what's going on? Can you share a code snippet on how you're using auth0.js so I can take a look? We did some state/nonce changes in previous versions, so make sure you're using the latest version.

[wpitallo]

I ended up changing to the following in my code: webAuth.parseHash(window.location.hash, (err, authResult) => and it seem to be ok, will do more testing tho. It must have been quite recently because I used quite a recent see here:

https://auth0.com/docs/quickstart/spa/vanillajs/01-login
this is still using webAuth.parseHash(function(err, authResult) {

or is this correct?

Might just be a case of documentation that's out of date?

[wpitallo]

Thx for the prompt response btw 🥇

[wpitallo]

I followed the tutorial in the link above and I am using auth0.min.js v8.10.1

[luisrudge]

Both should work, really. Are you saying that parseHash((err, authResult) => {}) throws the nonce doesn't match error but parseHash(window.location.hash, (err, authResult) => {}) doesn't? If that's the case, it's definitely a bug!

[luisrudge]

We had some changes in v8.11 and also had a security patch in v8.12, so you probably want to upgrade to the latest version so you can have the latest fixes!

[wpitallo]

Awesome will do that thanks!

[luisrudge]

@wpitallo by the way, the latest major is v9, so the latest version is 9.2.2.

[wpitallo]

Awesome thanks!!!