in the core, you can set the lifetime to the one that is the maximum value of the two flows.
The override the password reset creation recipe function, and once you have the token from the orginal impl call, you can change the token format to add some sort of a lower expiry to it like:
- If the token is
abcd
, you can make it
abcd-<timestamp>
. Where the value of
timestamp
is time in MS for when you want it to be invalid.
- Now override the token consumption API which will recieve this token as an input, and in there, you can check if the timestamp embedded in the token is lesser than now or not. If it is, then return an INVALID_TOKEN error, else strip away the
-<timestamp>
part and call the orginal implementation. You also need to be careful to enforce that the
-<timestamp>
must be present in the token if it's a regular password reset flow (you can do this by passing in a relevant user context object).
This has one issue that the
-<timestamp>
part of the code can be changed by the user on the frontend, but to prevent this, instead of simply appending
-<timestamp>
to the token, you can create a JWT (using our JWT recipe), which contains the timestamp and the actual reset password token in it. This is just a format change, but the overall idea is the same.