Auth0 Home Blog Docs

Problem with Lock v11 "Last time you logged in with" user flow




I have just upgraded the version of Auth0-lock from from 10.23.1 to 11.0.1.
I am using an embedded login page to display the Auth0 login dialog. On the initial page load and log in using a social provider (ie. Twitch) everything works fine, the user is authenticated and cookie data is set in the browser.
After a logout button is pressed the cookie data is destroyed, but the user is not actually logged out of Auth0. If the user navigates back to the login page, they are then presented with the Auth0 login that says: “Last time you logged in with” ie. this screen:
![logged in with][1]

If the user clicks “Not your account”, then the login flow work correctly. If the user clicks the email address, an API call is make to /authorize but the user is not redirected to the callback, so the user is never actually logged in to the app.

I am pretty sure this has something to do with the query params that are sent to the /authorize API that appear to be new for v11.

response_mode: web_message
prompt: none

I know I can disable this screen by setting the option ** rememberLastLogin** to false, but I would like to keep this screen. My question is how am I supposed to handle this use case so when the user clicks their email they are correctly logged in as if they used the regular login screen.

Code Snippet

Here is a code snippet in my react Login component componentDidMount function.

    const lock = new Auth0Lock(process.env.REACT_APP_AUTH0_CLIENT_ID, process.env.REACT_APP_AUTH0_DOMAIN, {
      container: 'auth0Lock',
      initialScreen: 'login',
      theme: {
        logo: 'https://path-to-logo/auth0/fa_anvil_rust_logo.png',
        primaryColor: '#985e6d', // default #ea5323
        authButtons: {
          'twitch': {
            primaryColor: '#6441A4',  // Twitch Purple
            icon: 'https://path-to-logo/auth0/twitch_glitch_wh_logo.svg'
      languageDictionary: {
        title: 'Let\'s get started!'
      auth: {
        redirectUrl: process.env.REACT_APP_AUTH0_REDIRECT_URI,
        responseType: 'token id_token',
        audience: process.env.REACT_APP_AUTH0_AUDIENCE,
        params: {
          scope: Auth.requestedScopes


This seems related to this question but is slightly different as I am not using the Hosted page.
Also I think the auth-lock lib is setting the response_mode and prompt automatically but there seems to be a logic error. According to the docs if prompt=none is present then they user should automatically redirect to callback uri. There seems to be a bug from the response_mode.


That question linked in the comment as you mentioned is different due to the use of the hosted page. What prompt=none implies is that an authorization response is immediately provided without triggering any user interaction, however, how that response is provided is still controlled by response_mode so depending on that value there may be actual no HTTP redirect to the redirect_uri.

In particular, with web_message response mode the authorization response is communicated through a postMessage to the parent window that triggered the request so there is no redirects happening in the main/parent window; this is by the draft specification associated with that response mode.

I gave it a few tests with Lock 11.0.1 and a similar configuration and in both cases:

  1. initial login
  2. completing login by clicking the last time you logged in with…

there was a common outcome; the Lock authenticated event was raised containing the authentication response. It’s true that behind the covers there was some technical differences. In the first scenario due to the requirements for user interaction HTTP redirects were performed in the main application window which results in the end-user going to the social authentication provider, a response from the social provider is given to your Auth0 tenant/domain and finally the Auth0 service redirects (actual HTTP redirect on main window) to the client application redirect_uri. This has the side-effect of loading the client application again in the browser.

For the second scenario, given prompt=none&response_mode=web_messagecan be used, the authentication request is performed in a child iframe and the Auth0 service responds with an authentication response that is communicated to the parent window by web message (there is no HTTP redirect to client application redirect_uri). The side-effect is that the client application is never fully reloaded so it needs to be ready to handle the Lock authenticated event in a way that updates the client application to reflect the new authentication state (assuming a success response that means setting the state to authenticated). In addition, given you’re using a container, you may also want to call lock.hide explicitly, but in the end it mostly depends on how you want to reach to the response; you could even just store the response in storage and force a full refresh of the application again so that now when booting up it picks everything from storage and considers the user authenticated.


Thanks for the info. Is this change and the support of “web_message” new to Lock v11? I assume this user flow will be the preferred method going forward, as it is less disruptive to the user and quicker?
It sounds like we’ll just need to update our app to add support for the triggered events from the Lock component.


The web message response mode is indeed relatively new; it was introduced around the time that that checkSession method was introduced in Auth0.js v8 so from that I know it predates Lock 11, however, I’m unsure if more recent version of Lock 10 already made any use of it or not; would have to check. Having said that, yes, the recommended approach would be prepare the application for it as the release of Lock 11 deprecated all other versions for embedded login scenarios.


Hi - sorry, I reread this solution several times, but still don’t understand what the answer is. I have the same issue as the OP – I am using embedded login form, but when the user clicks on the “last time you logged in with” button, no redirect happens. It just says “Thank you for logging in”, but does not log the user in // no redirect happens, and as far as I can tell, the “authenticated” event is not emitted (or at least not in a way that I can detect). Could you please provide additional detail on how to change the configuration (for embedded) so that sso works?