Support account lockout with identity endpoints

[halter73]

Background and Motivation

Add alternative authentication scheme support a number of SignInManager APIs that support features such as 2fa and lockout.

Proposed API

// Microsoft.AspNetCore.Identity.dll

namespace namespace Microsoft.AspNetCore.Identity;

public class SignInManager<TUser> where TUser : class
{
+    public string PrimaryAuthenticationScheme { get; set; } = IdentityConstants.ApplicationScheme;
}

Usage Examples

routeGroup.MapPost("/login", async Task<Results<Ok<AccessTokenResponse>, ProblemHttpResult, IResult>>
    ([FromBody] LoginRequest login, [FromQuery] bool? cookieMode, [FromQuery] bool? persistCookies, [FromServices] IServiceProvider sp) =>
{
    var signInManager = sp.GetRequiredService<SignInManager<TUser>>();

    signInManager.PrimaryAuthenticationScheme = cookieMode == true ? IdentityConstants.ApplicationScheme : IdentityConstants.BearerScheme;
    var isPersistent = persistCookies ?? true;

    var result = await signInManager.PasswordSignInAsync(login.Username, login.Password, isPersistent, lockoutOnFailure: true);

    if (result.RequiresTwoFactor)
    {
        if (!string.IsNullOrEmpty(login.TwoFactorCode))
        {
            result = await signInManager.TwoFactorAuthenticatorSignInAsync(login.TwoFactorCode, isPersistent, rememberClient: isPersistent);
        }
        else if (!string.IsNullOrEmpty(login.TwoFactorRecoveryCode))
        {
            result = await signInManager.TwoFactorRecoveryCodeSignInAsync(login.TwoFactorRecoveryCode);
        }
    }

    if (result.Succeeded)
    {
        // The signInManager already produced the needed response in the form of a cookie or bearer token.
        return TypedResults.Empty;
    }

    return TypedResults.Problem(result.ToString(), statusCode: StatusCodes.Status401Unauthorized);
});

Alternative Designs

Add half a dozen or more overloads to PasswordSignInAsync, TwoFactorAuthenticatorSignInAsync, TwoFactorRecoveryCodeSignInAsync, etc... that take the primary authentication scheme.

Maybe come up with a better name.

Risks

We have to add even more properties like this in the future and all the state becomes unweildy.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes:

• Discussed why adding parameters to a lot of methods rather than a property could work but would be a lot noisier.
• We don't think the "Primary" in PrimaryAuthenticationScheme is adding much. Let's just go with AuthenticationScheme instead.
• What about SignInScheme?
  • We don't think "SignIn" adds value since this is a property on the SignInManager.

API Approved!

// Microsoft.AspNetCore.Identity.dll

namespace namespace Microsoft.AspNetCore.Identity;

public class SignInManager<TUser> where TUser : class
{
+    public string AuthenticationScheme { get; set; } = IdentityConstants.ApplicationScheme;
}