Authentication with ASP.NET Core Identity

Understand the idea

Authentication answers “who is making this request?” Identity supplies account management, password hashing, security tokens, and integrations for sign-in. Cookie authentication lets a browser carry an authenticated session between requests. Authorization then decides what that authenticated user may do.

TaskBoard uses the standard Identity UI rather than inventing password storage. Its local learning configuration permits registration without email confirmation so you can run it immediately. A public deployment needs a real email workflow and a deliberate account policy.

Register Identity and its storage

AddDefaultIdentity configures the default Identity UI services. AddEntityFrameworkStores connects those services to BoardDb. AddRoles adds role services; roles do not appear merely because a controller mentions an Admin role.

The password policy is a local teaching baseline. Do not log passwords or build a custom hashing function. Identity’s supported password hasher stores a salted password representation; account recovery and confirmation use dedicated token mechanisms.

builder.Services.AddDefaultIdentity<IdentityUser>(options =>
{
    options.SignIn.RequireConfirmedAccount = false; // local learning only
    options.Password.RequiredLength = 10;
})
.AddRoles<IdentityRole>()
.AddEntityFrameworkStores<BoardDb>();

Connect the HTTP pipeline

Authentication reads the incoming cookie and builds HttpContext.User. Authorization evaluates the selected endpoint’s requirements against that principal. Keep authentication before authorization, and map Razor Pages because Identity’s UI is implemented with Razor Pages even when the main app uses MVC views.

The frameworks coexist naturally. A controller can use [Authorize] while registration and login live under /Identity/Account. The shared layout provides consistent navigation across both kinds of page.

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
app.MapRazorPages();

Observe a protected request

Open /Tasks in a private browser window. Without a session cookie, you are sent to the login flow. Register a user, sign in, and repeat the request. The controller can now obtain the user identifier from the principal’s NameIdentifier claim.

Use the stable user id as the ownership key, not the display name or email. Emails can change. An authorization attribute ensures the claim is available from the configured authenticated Identity principal, but ownership checks remain necessary for individual records.

[Authorize]
public class TasksController(BoardDb db) : Controller
{
    private string OwnerId =>
        User.FindFirstValue(ClaimTypes.NameIdentifier)!;
}

Plan the public account lifecycle

Before publishing a real service, configure email delivery, confirmation, password reset, secure transport, and account recovery behavior. Test the entire lifecycle, including expired links and users who never receive a message. A login form alone is not a complete account system.

Keep development-only conveniences explicit. Do not ship shared administrator passwords in source code. Configure persistent data-protection keys when deploying multiple instances or replacing containers, otherwise authentication cookies and protected tokens may become invalid unexpectedly.

Anonymous /Tasks → login challenge
Valid credentials → authenticated cookie
Authenticated /Tasks → user’s own task list
Sign out → protected page challenges again
Second account → no access to first account’s tasks

When something doesn't work

A redirect loop can mean the login endpoint itself is protected by an overly broad policy.

If registration succeeds but sign-in requires confirmation, inspect RequireConfirmedAccount and whether an email sender is configured. Do not disable confirmation globally on a public service to bypass a broken mail setup.

Missing Identity pages usually means MapRazorPages or the Identity UI package is absent.