.NET Core：IIS Express认证正常，切换Kestrel后登录认证异常求助

Hey there! I’ve run into this exact head-scratcher a few times when switching between IIS Express and Kestrel—let’s walk through the most likely fixes to get your auth working smoothly on Kestrel.

1. Fix Cookie Authentication Configuration #

IIS Express handles some cookie settings quietly in the background, but Kestrel needs you to explicitly define them. If your auth cookie isn’t saving or being sent correctly, you’ll get that "successfully logged in" illusion without actual authentication.

Update your authentication setup in Program.cs to lock in these critical settings:

using Microsoft.AspNetCore.Authentication.Cookies;

// ...

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.Cookie.Name = ".AspNetCore.Identity.Application";
        options.Cookie.SameSite = SameSiteMode.Lax; // Lax is safe for most local development
        options.Cookie.SecurePolicy = CookieSecurePolicy.None; // Switch to Always if using HTTPS exclusively
        options.Cookie.HttpOnly = true;
        options.LoginPath = "/Account/Login";
        options.LogoutPath = "/Account/Logout";
    });

• If you’re testing over HTTP (not HTTPS), CookieSecurePolicy.None is non-negotiable—Kestrel won’t save the cookie otherwise.
• Double-check the cookie name matches what your Identity setup uses (if applicable).

2. Verify HTTPS and Kestrel Launch Settings #

If your IIS Express setup uses HTTPS but Kestrel is running on HTTP, this breaks cookie persistence instantly. Check your launchSettings.json to align Kestrel’s URL config:

"profiles": {
  "Kestrel": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "applicationUrl": "https://localhost:5001;http://localhost:5000",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development"
    }
  }
}

For local HTTPS testing, trust the dev certificate by running dotnet dev-certs https --trust in your terminal.

3. Check Session and Middleware Order #

If you’re using session state with authentication, middleware order is make-or-break—session needs to initialize before authentication for auth state to stick.

In Program.cs, arrange your middleware like this:

// ...

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseSession(); // Must come BEFORE UseAuthentication
app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();
app.MapRazorPages();

app.Run();

Also, add session services at the top of your setup:

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(30);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});

4. Enable Debug Logging for Authentication #

If the above fixes don’t work, turn on detailed auth logs to pinpoint where the flow fails. Update your appsettings.json:

"Logging": {
  "LogLevel": {
    "Default": "Information",
    "Microsoft.AspNetCore.Authentication": "Debug"
  }
}

Run your app with Kestrel, then check the console logs for messages about cookie creation, authentication attempts, or failures. This will tell you if the cookie isn’t being sent with subsequent requests, or if there’s an issue with the authentication ticket.

5. Confirm Identity Sign-In Logic #

If you’re using ASP.NET Core Identity, double-check your login action to ensure you’re properly signing in the user:

public async Task<IActionResult> Login(LoginViewModel model)
{
    if (ModelState.IsValid)
    {
        var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);
        if (result.Succeeded)
        {
            // Redirect to an action that uses [Authorize] to test auth state
            return RedirectToAction("Index", "Dashboard");
        }
        ModelState.AddModelError(string.Empty, "Invalid login attempt.");
        return View(model);
    }
    return View(model);
}

Make sure PasswordSignInAsync returns Succeeded, and that your redirect target uses the [Authorize] attribute to verify auth works.

内容的提问来源于stack exchange，提问作者Rawcy