3.x facade, kept for compatibility
AddAuthEndpoints and MapAuthEndpoints are the 3.x facade. They are not obsolete. Names, options, AuthEndpointsSignIn, EmailCode.Enabled, and the /identity, /account, and /auth routes stay at 3.4.1. New hosts that want one password session use Password auth. Do not call both facades in one host.
builder.Services.AddAuthEndpoints<AppUser, AppDbContext>(options =>
{
options.Passkeys.ServerDomain = "example.com";
});
app.UseAuthEndpoints();
app.MapAuthEndpoints<AppUser>();
Identity bearer is AddAuthEndpoints<AppUser, AppDbContext>(AuthEndpointsSignIn.IdentityBearer, ...). JWT on this facade is options.Jwt.Enabled = true plus Jwt.Configure. Passkeys are on until Passkeys.Enabled is false. Email-code sign-in is off until EmailCode.Enabled is true.
There is no role overload on AddPasswordAuth. The three-type AddAuthEndpoints<TUser, TRole, TContext> overload is unchanged. Your DbContext must be IdentityDbContext<TUser, TRole, TKey> or equivalent. Do not chain .AddRoles<TRole>() after the two-type overload.
The changes that do apply to this facade are in Upgrade to 4.0. Password login, JWT POST /create failure text, and email-code verify stay on the 3.4.1 handlers, apart from those exceptions. POST /manage/password stays unmapped here. The password facade maps it.
MapBearerAuthEndpoints maps no CSRF token route. Anonymous passkey ceremonies still need a token, because the WebAuthn challenge is stored in a cookie. Map a token endpoint in the host:
using Microsoft.AspNetCore.Antiforgery;
app.MapGet("/identity/csrfToken", (IAntiforgery antiforgery, HttpContext context) =>
Results.Ok(new { csrfToken = antiforgery.GetAndStoreTokens(context).RequestToken }));
The client keeps the antiforgery cookie from that response and sends the token in the RequestVerificationToken header. If you do not use passkeys, set Passkeys.Enabled to false instead. The skip rule is in Antiforgery (CSRF) rules.