Auth0 Home Blog Docs

V11 - Uncaught error: accessToken is not valid

lock-10
migration
lock-11

#1

Given the impending deprecations we are updating our React 15 app from auth0-lock v10 to v11. In doing so we are experiencing the following error:

BlockquoteUncaught Error: accessToken parameter is not valid
at variable (index.js:35152)
at Object.check (index.js:35152)
at Authentication.userInfo (index.js:35152)
at index.js:35152
at index.js:35152
at IdTokenVerifier.verify (index.js:35152)
at WebAuth.validateToken (index.js:35152)
at WebAuth.validateAuthenticationResponse (index.js:35152)
at WebAuth.parseHash (index.js:35152)
at Auth0APIClient.parseHash (index.js:35152)
at Auth0WebAPI.parseHash (index.js:35152)
at parseHash (index.js:35152)
at index.js:35152
at List.__iterate (index.js:35152)
at List.forEach (index.js:35152)
at resumeAuth (index.js:35152)

Using the lock webpack example appears to operate correctly, we are using the same parameters, ClientID and domain in both applications. Neither the ‘authenticated’ or ‘authorization error’ events are fired when this error occurs. Any help is gratefully appreciated.


#2

are you still having this issue? what version are you trying?


#3

Hi Luis, yes we are. In the meantime we have managed to massage popup mode into a state where it works but for us we get one of three behaviours:

  1. a blank popup window opens, closes, then we are logged in
  2. a new blank chrome tab opens, closes, then we are logged in
  3. a new blank chrome window opens, closes then we are logged in

Its very frustrating from a user experience perspective as it was not the behaviour of the previous version. The lock component also seems unable to remember the last login.

We have also noticed the lock component is leaking nonce data into local browser storage. It hasn’t caused a problem yet but will sooner or later.


#4

can you please share what version you’re using? Ideally, you should upgrade to the latest version and try again. Also, what are your lock configurations etc.


#5

Hi Luis, I have just been re-testing with v11.6.1 and still having the same issue. We also noticed impersonation is no longer working, this is a huge problem for us as we have some automated processes which depend on impersonation to login. Our lock is configured as follows:

this.auth0Lock = new Auth0Lock(config.authClientId, config.domain, {
  theme: {
    logo: logo
  },
  auth: {
    redirect: false,
    sso: true,
    params: {
      scope: 'openid app_metadata'
    },
    responseType: 'token id_token'
  },
  avatar: null,
  closable: false,
  hashCleanup: false,
  _enableIdPInitiatedLogin: true
})

#6

Do you get the accessToken parameter is not valid error only when impersonating?


#7

No, when we attempt with the impersonation URL we get re-routed back to the login screen always. No errors in the logs or any indication of what went wrong. We are using a hash url in our web interface which I believe may be the cause of some redirection problems but I don’t know how to work around that.


#8

so, all normal login attemps get the accessToken error.
all impersonation attempts redirect you to the login page.

Can you give me a code snippet of how you’re using lock? The impersonation thing shouldn’t redirect anywhere at all.


#9

Hi Luis, unfortunately I don’t have a code snippet much different to what I have already posted. There are a couple of further lines configuring the event listeners but that’s pretty much it. Prior to the update our configuration was set as:

this.auth0Lock = new Auth0Lock(config.authClientId, config.domain, {
  theme: {
    logo: logo
  },
  auth: {
    params: { scope: 'openid app_metadata' }
  },
  closable: false,
  hashCleanup: false
})

which worked perfectly well for us (v10.16.0).


#10

I meant around this:

We are using a hash url in our web interface which I believe may be the cause of some redirection problems but I don’t know how to work around that.

Do you mean react router with browser history?


#11

Yes exactly. I am not certain which version of react router we are currently using.


#12

Hi, I tried to reproduce this locally but I couldn’t. As you said, the same configuration works elsewhere. Do you think you can reproduce this in an isolated example so I can help you debug it?


#13

Hi Luis, as mentioned in the initial post I cannot reproduce this issue in the auth0-react samples unfortunately. I am however able to produce the impersonation issue using the embedded login sample application. I will speak with our engineers and see if we can re-create the issue in an application we can distribute.


#14

Ideally, it would be better to reproduce the issue outside of your application, so we make sure it’s not related to your app.


#15

Hi Luis, thanks for the help so far. I have undone the workaround in our application and have maybe made some progress. Our lock configuration is as follows:

this.auth0Lock = new Auth0Lock(config.authClientId, config.domain, {
  theme: {
    logo: logo
  },
  auth: {
    redirect: true,
    sso: true,
    params: {
      scope: 'openid app_metadata'
    },
    responseType: 'token'
  },
  avatar: null,
  closable: false,
  hashCleanup: false,
  autoclose: true
})

In this configuration the authResult.accessToken returned is undefined, this prevents us accessing the user profile however the access_token is present in the browser URL. I have attempted to set an audience however we get the error:

Uncaught Error: It is not possible to use the `auth.audience` option when the `oidcConformant` flag is set to false

It is true that this flag is set to false however we do not see the error in auth0-react-samples.


#16

You can’t get this error if you’re using v11. This error is only thrown in v10:

v11 version:

My feeling is that you’re somehow messing up the url handling and you’re getting access_token undefined because of this issue. If you can create this issue on codesandbox.io, that would be the best way to help you out on this. You can find a ready-to-go example with react-router here: https://codesandbox.io/s/r0wXp0Njw


#17

Thanks Luis, my package.json and package-lock.json contents are as follows:

package.json

"dependencies": {
"ajv": "^4.10.0",
"auth0-lock": "^11.6.1"

package-lock.json

"auth0-js": {
  "version": "9.5.1",
  "resolved": "https://registry.npmjs.org/auth0-js/-/auth0-js-9.5.1.tgz",
  "integrity": "sha1-NN6msPEbXl7hOWBWEfSbHA8V27E=",
  "requires": {
    "base64-js": "^1.2.0",
    "idtoken-verifier": "^1.2.0",
    "js-cookie": "^2.2.0",
    "qs": "^6.4.0",
    "superagent": "^3.8.2",
    "url-join": "^1.1.0",
    "winchan": "^0.2.0"
  },
  "dependencies": {
    "url-join": {
      "version": "1.1.0",
      "resolved": "https://registry.npmjs.org/url-join/-/url-join-1.1.0.tgz",
      "integrity": "sha1-dBxsL0WWxIMNZxhGCSDQySIC3Hg="
    }
  }
},
"auth0-lock": {
  "version": "11.6.1",
  "resolved": "https://registry.npmjs.org/auth0-lock/-/auth0-lock-11.6.1.tgz",
  "integrity": "sha1-M3wyaAUPw247ALLgJ2v15iCRZAk=",
  "requires": {
    "auth0-js": "^9.5.1",
    "blueimp-md5": "2.3.1",
    "fbjs": "^0.3.1",
    "immutable": "^3.7.3",
    "jsonp": "^0.2.0",
    "password-sheriff": "^1.1.0",
    "prop-types": "^15.6.0",
    "react": "^15.6.2",
    "react-dom": "^15.6.2",
    "react-transition-group": "^2.2.1",
    "trim": "0.0.1",
    "url-join": "^1.1.0"
  },
  "dependencies": {
    "url-join": {
      "version": "1.1.0",
      "resolved": "https://registry.npmjs.org/url-join/-/url-join-1.1.0.tgz",
      "integrity": "sha1-dBxsL0WWxIMNZxhGCSDQySIC3Hg="
    }
  }
},

#18

can you please type npm ls auth0-lock and cat node_modules/auth0-lock/package.json | grep version and paste the responses here, please? The codepath you’re running doesn’t exist in 11.x, so there’s something wrong somewhere.


#19

Ok, I think we reached a workable situation. There were several contributing factors:

  1. Establishing which settings were required for accessToken AND idTokens to be returned
  2. Updating getProfile to getUserInfo utilising the accessToken
  3. Establishing that the URL containing the accessToken had changed and required custom parsing using the resumeAuth method
  4. Making sure NPM actually updated dependencies and wasn’t using locally cached dependencies. This may be a result of subsequent build steps which can create caches

Our configuration stands thus:
this.auth0Lock = new Auth0Lock(config.authClientId, config.domain, {
theme: {
logo: logo
},
auth: {
redirect: true,
sso: true,
params: {
scope: ‘openid app_metadata’
},
responseType: ‘token id_token’
},
avatar: null,
closable: false,
hashCleanup: false,
autoParseHash: false,
_enableIdPInitiatedLogin: true
})

this.auth0Lock.resumeAuth(window.location.hash.split('?')[1], (error, authResult) => {
  if (error) {
    this._onError(error)
    return
  }
})

this.auth0Lock.on('authenticated', (authResult) => this._onAuthenticated(authResult))
this.auth0Lock.on('authorization_error', (error) => this._onError(error))

and seems to be working fine now.