IdentityApiEndpointRouteBuilderExtensions should not create the ConfirmationLink

[JJong-nl]

The IdentityApiEndpointRouteBuilderExtensions should never create a ConfirmationLink but must be dealing with codes only.

When we see the implementation of IEmailSender<TUser>
We see SendConfirmationLinkAsync, SendPasswordResetCodeAsync and SendPasswordResetLinkAsync

Here the SendPasswordResetLinkAsync and the SendConfirmationLinkAsync should be removed and a SendConfirmationCodeAsync should be added.

The SendPasswordResetCodeAsync is used in the ApiEndpoint but SendPasswordResetLinkAsync is never used in the Api.
Only in the UI implementation.

When we want to generate a link instead of using the code, we should generating the link inside the IEmailSender<TUser> implementation.

So only SendConfirmationCodeAsync and SendPasswordResetCodeAsync sould be sufficient in the IEmailSender<TUser> interface

IdentityApiEndpointRouteBuilderExtensions.cs

aspnetcore/src/Identity/Core/src/IdentityApiEndpointRouteBuilderExtensions.cs

Lines 214 to 217 in 65f485e

	var code = await userManager.GeneratePasswordResetTokenAsync(user);
	code = WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(code));
	await emailSender.SendPasswordResetCodeAsync(user, resetRequest.Email, HtmlEncoder.Default.Encode(code));

ForgotPassword.cshtml.cs

aspnetcore/src/Identity/UI/src/Areas/Identity/Pages/V5/Account/ForgotPassword.cshtml.cs

Lines 75 to 83 in 65f485e

	var code = await _userManager.GeneratePasswordResetTokenAsync(user);
	code = WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(code));
	var callbackUrl = Url.Page(
	"/Account/ResetPassword",
	pageHandler: null,
	values: new { area = "Identity", code },
	protocol: Request.Scheme)!;
	await _emailSender.SendPasswordResetLinkAsync(user, Input.Email, HtmlEncoder.Default.Encode(callbackUrl));

The ForgotPassword.cshtml.cs should also be using the SendPasswordResetCodeAsync inside the implementation of the emailsender we sould generate the callbackUrl.

[JJong-nl]

Maybe,
Rename the IEmailSender<TUser> to the following

public interface IIdentityCoreEventHandler<TUser> where TUser : class
{
    Task UserLogedInAsync(TUser user);
    Task UserLogedOutAsync(TUser user);
    Task EmailConfirmedAsync(TUser user);
    Task EmailChangedAsync(TUser user, string oldEmail, string newEmail);
    Task PasswordChangedAsync(TUser user, string oldPassword, string newPassword);
    Task EmailChangedAsync(TUser user, string oldEmail, string newEmail);
    Task SendConfirmationCodeAsync(TUser user, string email, string confirmationCode);
    Task SendPasswordResetCodeAsync(TUser user, string email, string resetCode);
    . . .
}

[MackinnonBuck]

Thanks for reaching out.

Could you please clarify what the motivation behind this change is? What's your exact scenario? Is the purpose of this API just to create more consistency?

[JJong-nl]

In my first two comment i pull out two isseus.

1. The confirmation url endpoint should not be created in the IdentityApiEndpointRouteBuilderExtensions 'and' not go to the API endpoint.
2. More intercepters on 'every' outcoming of the API that can be handled with an IIdentityCoreEventHandler (instead of two handlers in the IEmailSender)

First explaining the first issue.
When we host a application on domain A and the API is hosted on domain B.
The application 'can' access the API serverside, and the API has non-public access.

Therefore the user does only interact with domain A.
The problem here is that the API is creating a direct link to domain B.

When we see the /forgotPassword SendPasswordResetCodeAsync only a code is returned.
The developer has to know the api endpoint of the /resetPassword and send this from domain A to the API on domain B.

This should also be the solution for the confirmation.
The /register and /resendConfirmationEmail endpoints should only call the emailSender with the code, not the url of the confirmation.
Than withing the logic of the emailSender the confirmation url can be constructed this can be a link to domain A with querystring, and domain A has the knowledge what to do with it. (construct and call confirmation endpoint on domain B)

Second: more eventhandlers for every scenarion of the API. (success and failure)
With this approach the developer has total freedom to do what he fits best in every scenario.
This will also replace the IEmailSender<Tuser> to for example IIdentityCoreEventHandler<TUser>
For example when there are 3 failed login attempts for a single user (UserLoginFailedAsync), the user can be notified with an email.
Or when a user is requesting to change his email, also a notification to his 'old' emailadress can be send.
Or when a success login is called extra checks can be inplemented. (new login on a machine? user can be notified)

public interface IIdentityCoreEventHandler<TUser> where TUser : class
{
    Task UserLogedInAsync(TUser user);
    Task UserLoginFailedAsync(string email, SignInResult result);
    Task UserLogedOutAsync(TUser user);
    Task EmailConfirmedAsync(TUser user);
    Task EmailChangedAsync(TUser user, string oldEmail, string newEmail);
    Task PasswordChangedAsync(TUser user, string oldPassword, string newPassword);
    Task SendConfirmationCodeAsync(TUser user, string email, string confirmationCode);
    Task SendPasswordResetCodeAsync(TUser user, string email, string resetCode);
    . . .
    . . .
}