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

Help
,
1

Overview

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
        }
      }
    });

    lock.show();
2

This seems related to this question but is slightly different as I am not using the Hosted page.
http://community.auth0.com/questions/2263/seeing-last-time-you-logged-in-with-during-authori
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.

3

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.

4

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.

5

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.

6

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?

2 Likes
7

@elee Did you ever get this working? I can’t figure out what the answer is even trying to say lol

8

@tbaustin was able to solve this, although my solution may or may not be generally applicable (my fix might only be applicable to Angular 1?)

Anyways, the problem was that the lock in Section 1 here:

var lock = new Auth0Lock(
  'clientId',
  tenantUrl'
);

has to be the same as the “lock” reference pointer in Section 2.

lock.on("authenticated", function(authResult) {

That seems obvious in retrospect, but I think where I got confused was:

  1. in the older lock SDK, the initialize method was more of a “global” scope (ie. lockProvider.init)
  2. in the older lock SDK, you could inject “lock” as a dependency injection

Anyways, as mentioned, the fix was just to make sure that the lock initialized in the “new Auth0Lock” is passed to the event listener → lock.on(“authenticated”

Hopefully that makes sense! Let me know if any of what I said was obscure or vague, and as mentioned this might be a framework-specific fix.

10

or, to change the variable name to make this hopefully more clear:

var myLocalLock = new Auth0Lock(
‘clientId’,
‘tenantUrl’
);

myLocalLock.on(“authenticated”, function(authResult) {

^ the fix was to make sure that the lock I initialized (ie. myLocalLock) up top (var myLocalLock = new Auth0Lock() was being passed to the listener for ‘authenticated’ → myLocalLock.on(“authenticated”,

11

I don’t actually use lock.on() in my application. I am using react. All I do is call lock.show() when the user logins and it goes to the callback url and the auth0 config takes it from there. I am not sure where to even call lock.on() in my application haha. Thanks for the help though I will look more into it.

12

@tbaustin got it – may or may not be helpful:

my guess is that you need to put the lock event listener (ie. section 2 here: https://auth0.com/docs/libraries/lock/v11) right after your lock.show() → that’s what worked for me and i think that should be the same for angular or react (at least that’s my guess)

1 Like
13

@elee’s answer is the correct one. Thanks!

I’m also implementing this for a React app. I created a component that simply initializes Auth0 Lock.

The resulting code looks like this:

const lock = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN, options);
lock.show();
lock.on("authenticated", authResult => auth.setSession(authResult));

Obviously you need to bring auth in scope (an instance of the Auth class from the official Auth0 React samples).

If you’re using Auth0Lock to authenticate, you can scrap the authentication code from that Auth class.

14

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