I'm trying to implement authentication for users on a web page using JWT tokens and, so far, I can create users and authorize them. I'm now trying to write the password reset functionality and I think I may be finished (per any examples and research I find) and the process looks pretty standard...
- A user will click "reset password" and enter their email address and then the server will generate a token, append it to a URL as a link and send that to the email address. The back end will have a record of this open request for the next 30 to 60 minutes and purge the record if the user never clicks.
- If the user clicks the link from email, the token in the url query parameter will be verified and marked as "claimed" and a page will load with an input text box for a password and a submit button.
At this point, most examples will POST the password back with the same token that was sent in the email and re-verify the token again and accept the password. Is there any problem with using the same token again after it was claimed from the email click? I am not a hacker so I don't know all the exploits to be aware of but I just assumed that this isn't the "right way" to do it because even if the token is claimed and nobody can come back through that path, if the attacker gets the token from the URL query (which seems easy) then they could just POST back their own password with the token to finish the process, right?
I can think of a way to mitigate that problem but I guess I'm asking if this is an actual problem.
