Why do we need both token and email in password reset submit?

[rootcause0]

The typical Password Reset flow involves the user receiving a password reset link with a token, clicking on it, and being directed to a form where they input a new password. In many implementations, the user's email is not required on this form, as the token itself should suffice to identify the user (as it is unique and tied to the user's email in the database).

Could you provide insight into the decision to require both the email and token in the reset request? Are there security considerations or other reasons behind this design choice?

Furthermore, would it be feasible to consider a native approach where only the token is required, simplifying the reset process and aligning with common user expectations?

I'm inquiring about this because I've noticed that it's not obligatory to submit the 'email' to the backend during a password reset submission on most modern apps. Typically, you would send your token, and since that token is associated with an email, the process would be completed. Obviously, there would be no input field for the email in the password reset form, only fields for the new password and its confirmation.

Thank you in advance for any insights or explanations you can provide.

[donnysim]

The logic is from 2013 maybe even older so if I'm sure they would do it differently now and it would be possible to encode the email or other user identifier to the token and read it in the broker (note that it's an email and not user id because you might have multiple "user" tables etc.). That said, changing this now would introduce breaking changes with database structure and applications/packages that depends on current behavior, but there's nothing preventing the developer overriding the reset email with his own and he can include the email inside custom encoded token - encode('email|token') and decoding it into segments when handling reset, which not sure it warrants a breaking change for such a thing as it's trivial to do and most are fine with current logic.

Personally I would prefer single token out of the box but it's not something I'm too bothered by and it's fast to workaround and I usually run my own boilerplate with preferred changes.

[rootcause0]

Yeah, it feels like this part gets a bit overlooked in such a modern framework. I'm not convinced it would break the framework if they tweaked it. I wasn't aware that it was because of the old implementation of that logic, but I still don't get why the single token is not even considered in the first place. As far as I can remember, the old applications at that time also did this kind of operation based only on one token, not pairing it with the email.
Anyway, thanks for the explanation.