Auth0 lock error from my Frontend

General
#1

I’ve used auth0 Lock in my application. I have two enviroments (tenants) in auth0, in one I use the database connection Username-Password-Authentication, this one works OK. In the other I have created a database, and use this connection. I created new users (in the users section) linked to this connection, I tried the connection in auth0 dashboard and everything works fine. However when I tried to login from my website, it’s says something goes wrong. I checked in Network and it is returning the authentication call OK, but nothing else after that:

36%20AM
36%20AM1458×294 32.8 KB

In the auth0 logs it says:
Type: Failed cross origin authentication|

Description: Consent required

I have configured in the Applications the ‘Allowed Callback URLs’ the URL from where I call: ‘http://localhost:3000/attendance’ and ‘Allowed Web Origins’ I put ‘http://localhost:3000’, I put the correct Client ID and Domain.

What could I be making wrong? I configured the Applications in the different tenants equal, but one is working and the other one no.

#2

The issue is right there in the error description: Consent required. When logging in from localhost, Auth0 will always display a user consent screen the first time they log in to that connection. For some reason, it can’t do that here and just blocks the whole login attempt. For more info about the consent dialog on localhost, see this docs article.

So, the question now is: why isn’t Auth0 able to just redirect the user to the consent dialog? How are you handling your login? Is it embedded Lock, or are you using Universal Login?

#3

I am handling the login with Auth0 Lock. I have this in my JS code:

const lock = new Auth0Lock('[customer_id]', '[domain]', {
  auth: {
    redirect: false,
    responseType: 'token id_token',
    params: {
      scope: 'openid email user_metadata app_metadata picture', 
    },
  },
  allowedConnections: ['AIME-Recruitment'],
  theme: {
    logo: 'https://d2ylaz7bdw65jx.cloudfront.net/assets/images/aime-logo.svg',
    primaryColor: '#005D97',
  },
  languageDictionary: {
    title: "AIME Log In",
  },
});

and then:

lock.on("authenticated", (authResult) =>; {
......
}

I don’t remember seeing a user consent screen when I login in to the other environment (the tenant where the app is working). I don’t understand why I need a consent if I created the user from auth0 dashboard and then confirm this with the user email.

Anyway, it seems like it make the login OK but it never redirects to this consent dialog and neither send the user info, I don’t know why.

#4

Can you try changing your scope to openid profile email? According to this migration guide, not setting it to at least those three values could throw an error.

#5

I changed it, but the same…

const lock = new Auth0Lock('Po34fKQ4UmW1AEnIRJ0tPch51WNM5lWc', 'aimementoring-staging.auth0.com', {
  auth: {
    redirect: false,
    responseType: 'token id_token',
    params: {
      scope: 'openid profile email', 
    },
  },
  allowedConnections: ['AIME-Recruitment'],
  theme: {
    logo: 'https://d2ylaz7bdw65jx.cloudfront.net/assets/images/aime-logo.svg',
    primaryColor: '#005D97',
  },
  languageDictionary: {
    title: "AIME Log In",
  },
});
#6

Running into this same issues using passwordless when attempting to provide the update:current_user_metadata scope. Using ‘openid profile email’ alone works for me, but doesn’t allow me to perform any updating so i’m dead in the water without a token that can update a users metadata.

#7

Hi Syntaf1, sorry I’m not understanding you. You had the same issue but you could resolve it changing the scope params? I changed but do not resolve the issue.

#8

No, I’m saying I can’t fix this issue and have the same problem as you.

#9

Yup running into the same problem a year later.

#11

If anyone is still seeing this, it’s because the consent dialog only shows up when you set redirect: true within the auth options. See here: https://github.com/auth0/lock/issues/1672

As the user there mentioned, the docs really should probably make this clear.

#12

Thanks a lot for sharing that and sorry for inconvenience! Will relay that info to docs team!

#13