The problem is that your password reset token shouldn't be reusable. The token is only leaked after the person visited the reset page, which should invalidate the token on load.
Without a valid token, the reset form shouldn't load. Problem solved.
Without a valid token, the reset form shouldn't load. Problem solved.
I did consider this approach for Clearance and intended to go with it, but was discouraged from doing so after hearing reports that some enterprise email AV does things like open some links in emails.
There is also the user experience concern that a click the link in my email, do something else, then click the link again, having forgotten I already clicked the link. Now I'd have to re-request again.
Also, this approach is impossible if you use HMAC tokens.
I don't think anyone who opts for this approach is wrong but like most things, it's a tradeoff.
I think you should invalidate a token whenever a user enters a new password and submits a form (hence POST).
I might not be using the right term here, but the general idea is that you create an encrypted token out of some data and verify that the data is unchanged and still valid on the server. In that way you can provide a token that ensures the user had access to the link you sent them, but you don't have to store it in the database.
But some sort of token needs to be used even after clicking the email link because the "enter a new password" form needs it posted as well (to prevent people from using that form willy-nilly on any account).