Logging the reason behind "InvalidToken" response from UserManager.ConfirmEmailAsync method

[jaslam94]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Problem I have been getting an "InvalidToken" response from the ConfirmEmailAsync method in a .NET 7-based API project. Error description contains "Invalid token". The token can be invalid for multiple reasons, including missing characters, inconsistent data protection key and expiration. The reason should be logged otherwise debugging this problem becomes almost impossible.

Describe the solution you'd like

The proper detailed reason for the email confirmation token being "invalid" should be logged by the framework.

Additional context

No response

[lonix1]

From my closed issue #12672:

Background

Identity's UserManager does not behave consistently when confirming tokens.

Examples:

I can call userManager.ConfirmEmailAsync(...) multiple times, and it will succeed each time even though the token was already redeemed. This tells me that although the token was redeemed, it is still valid and unexpired.

I can call userManager.ChangeEmailAsync(...) only once successfully, and will return errors afterwards. This tells me that the token is 1) invalid or 2) expired or 3) redeemed.

There are other such methods, with the same inconsistency.

Problem

This inconsistency makes it difficult/impossible to correctly interpret errors for the user.

Is the token "invalid", or is it expired, or is it simply already redeemed? Those are different errors, and they lead to two different actions by the user.

This is a source of friction for our users, who end up in a never-ending loop of redoing some action, then incorrectly interpreting the error and asking for another token, etc. And eventually they call us and we need to make the changes manually.

Solution

Please return a standard result from these related methods, so we can tell whether:

1. the token is invalid (possibly due to hacking, etc.), so no action was taken
2. the token is valid, but is expired, so no action was taken
3. the token is valid, but it has already been redeemed, so no action was taken
4. the token is valid, unexpired and unredeemed, so the action was taken

Even the MS security guru @blowdart agreed to backlog it, but it was closed.

I disagree it's related to "dev experience" - the API in a security-oriented feature has problems.