Having a separate changePasswordId expiry time for Setup-Password Flow than Forgot-Password Flow

[AmirEzati]

Having a separate changePasswordId expiry time for Setup-Password Flow than Forgot-Password Flow

Problem

We hit the forgot-password endpoint to first generate a changePasswordId and then use this value to send a customized setup password email after we invite users to an organisation. (infact we generate a link that behind the scene employs forgot-password flow) However, there is an issue here. Forgot-Password flow has a much shorter expiry time for the generated links using changePasswordId.(ex: 10 mins) , but for the setup-password, we need a much longer expiry time (ex: 24 hours) (This values as you know are configurable in the tenants advanced setting)

In other words, we need a separate changePasswordId which is not expired based on the expiry time set by forgot-password flow but by setup-password-flow.

[robotdan]

There are separate TTL configs for setup password and change password. Will these work, and if not, can you provide more details on how you are using these workflows so we understand why the existing configuration is not adequate?

[AmirEzati]

Yes, there are separate TTL. but the original problem we had is this:

• We create a user from our Backend without letting FusionAuth to automatically send the new user a setup-password email while we want to send them a customised email with some data that are only stored in our backend system.
• Then we use this endpoint POST /api/email/send/{emailTemplateId} to send a setup password email to the user. emailTemplateId refers to the setup-password-template
• And when the user opens the link and tries to define a password, they get this error:

-"Your password reset code has expired or is invalid. Please retry your request."

• We got some advice that says, instead we can use POST /api/user/forgot-password endpoint to mimic setup password flow. And now we are facing the issue of one TTL for two different purposes. Maybe you have another solution for this scenario which I assume should be a general use-case.

[robotdan]

Ok. Thank you for the additional information.

If I understand you correctly:

1. You are not using the setup password flow in FusionAuth. You wish to do this out of band.
2. So you are using the Forgot Password workflow to complete the Setup password workflow.

If this is the case, then you are correct, the TTL that will be used for the changePasswordId that you generate when you begin the forgot password workflow will be the TTL for the Change Password, and not the one configured for the Setup Password workflow.

This would be working as designed.

A couple of ideas:

1. You adjust the TTL for the Forgot Password TTL to something that would be reasonable for both the change password and setup workflow.
2. We re-purpose this issue to be an enhancement request to:
   • Add an API parameter to the User Create API to indicate you want to use the setup password flow, but do not wish to have FusionAuth send the email.
   • Have FusionAuth return the changePasswordId on the API response
   • Then you could consume this value and send the email out of band