Auto login after reset password

Hi
We are directing the user back to our site as soon as they set their password through the auth0 hosted change password screen and reset password flow.

I was kind of expecting a valid session to be created during the reset password flow, meaning that a call to checkSession would return back an access token and we would show the user as logged in without them being forced to re-enter their password.

Is that possible with the hosted change password page?

Thanks

2 Likes

I have the same need. I was also expecting that after inputing his new password the user would be logged in.

I found another issue (kind of related): Get Magic Link for Passwordless Login for Personalized Login E-mail , so I guess itā€™s not possible.

Right now Iā€™m using a trick for new users. Iā€™m setting a password that we generate server side, use the password with the ā€˜/oauth/tokenā€™ API to get the tokens and use them to create a redirect url that I feed to theā€™/api/v2/tickets/password-changeā€™ API. It returns me an link that allows the user to change his password and then redirect him to the site with valid credentials.

Sadly, it works only for the new users. Those who already have a password and want to change it will not be logged once changed, as I did not find a way to generate them the proper credentials without knowing their password.

Am I missing something? Is there an API endpoint to generate an accessToken without specifying the user password? (by providing the client private key for example).

2 Likes

I should be able to generate a link that allows anyone to log in as a user of my choice through the impersonation API. https://auth0.com/docs/user-profile/user-impersonation
I guess this was NOT meant to be used to log real users, and I donā€™t want to use it if Auth0 will not support this usage. It feels too much like a hack.

What are our choices? The only solution I currently see is to code the whole changePassword process ourself, sending our own emails, using our own APIs and generating the redirection link when saving the password.

Hey, do you mind sharing how you created the redirect url from the /oauth/token API please?

Hi there, Iā€™ve done the same thing, but I canā€™t work out the redirect part. How did you feed a redirect URL to the password-change API?

Thanks,

Itā€™s a 3 step process.

  1. Get a valid token with the login and password of the user. As I said, there is no way that I know to get it without having the password of the user. So you can only get this once, when the user set his password.
  2. Get an authorization token to call the change password API
  3. Get a change password link from the change password API and provide a link as ā€œresult_urlā€ with the proper token you got at step 1

Here is most of the code I wrote for this:

   const options = {
    method: 'POST',
    host: process.env.REACT_APP_AUTH0_DOMAIN,
    path: '/oauth/token',
    body: {
      grant_type: 'password',
      username: email,
      password: password, // plain text password of the user!!!
      client_id: process.env.AUTH0_CLIENT_ID,
      client_secret: process.env.AUTH0_CLIENT_SECRET
    }
  }

  const result = await requestJson(options)

 [...some other code...]
 
   const resultToken = await requestJson({
        method: 'POST',
        host: process.env.AUTH0_DOMAIN,
        path: '/oauth/token',
        body: {
          grant_type: 'client_credentials',
          client_id: process.env.AUTH0_NIC_CLIENT_ID,
          client_secret: process.env.AUTH0_NIC_SECRET,
          audience: `https://${process.env.AUTH0_DOMAIN}/api/v2/`
        }
      })

      if (!resultToken) {
        throw new Error(
          'Error during the generation of the access token.'
        )
      }

      const result = await requestJson({
        method: 'POST',
        host: process.env.AUTH0_DOMAIN,
        path: '/api/v2/tickets/password-change',
        headers: {
          Authorization: `Bearer ${resultToken.access_token}`
        },
        body: {
          result_url: `${process.env.APP_PUBLIC_URL}${process.env.AUTH0_CALLBACK_RELATIVE_URI}#access_token=${result.accessToken}&id_token=${result.idToken}&expires_in=86400&token_type=Bearer`,
          connection_id: process.env.AUTH0_INTERNAL_CONNECTION_ID,
          email: account.email,
          ttl_sec: 864000 // The ticket is valid 10 days. After that, the user will have to use the "forget password link"
        }
      })
1 Like

Excellent! Thank you so much for taking the time to post this. Got it working :+1:

You have a great day now

Hey Folks! Sorry that we werenā€™t able to get to it before and huge thanks a lot to all of you for sharing the case as well as the knowledge to solve it yourselves :pray:t3:

Can you explain the business reasons that make that we are able to generate links to reset passwords (and so takeover an account) and at the same time unable to generate a valid token without the user password?

1 Like

Incredible workaround. Bravo. I would also like to know the business case of why this isnā€™t easily possible.

1 Like

How is it, that every basic login action has to have a workaround / 10 steps to follow in order to get it working :frowning:

1 Like

The proposed workaround may cause security issues so I highly recommend using what the product supports out of the box for password reset flow.

As of today, resetting the password clears the user session so the best option is to redirect to the login page. E.g. once password reset completes, you may redirect the user to your app with result_url and then the app starts a new login flow automatically.

The proposed workaround may help a malicious user create an account on the target application and then get a password reset link for their account and send this link to a victim to trick them to log in unnoticed with their account. As the app canā€™t verify who clicked the link (it didnā€™t started the authentication so canā€™t check state for example) the victim may do some actions on the malicious user account unnoticed which may lead to security issues.

It is absolutely ridiculous that this is not possible after 5 (FIVE!!!) years after this was raised. Even if I write custom reset page (which cannot be completely custom, cause Auth0 still kinda forces you to go through /u/reset-password, whereas ā€œcustomā€ page lives at the /lo/reset)