OWIN登录失效：User.Identity.IsAuthenticated始终为false求助

Hey there, let's tackle this head-on—nothing's more frustrating than having your login logic look solid but still hitting User.Identity.IsAuthenticated = false in your Confirm action. Based on what you've shared, here are the most common fixes and checks to get your OWIN authentication working:

1. Validate OWIN Middleware Order #

Middleware order matters a lot in OWIN. Your cookie authentication middleware needs to run before any middleware that relies on authenticated users (like MVC routing). Double-check your Startup.Auth.cs or Startup.cs to ensure the order is correct:

public void ConfigureAuth(IAppBuilder app)
{
    // First, configure cookie authentication
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
        LoginPath = new PathString("/Account/Login"),
        // Add other settings like Provider, CookieName, etc.
    });

    // Then add other middleware (MVC, SignalR, etc.)
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

If UseCookieAuthentication comes after UseMvc, the identity won't be loaded in time for your controller actions.

2. Match AuthenticationType Everywhere #

When you create your ClaimsIdentity, the authentication type must exactly match the one defined in your CookieAuthenticationOptions. The most common mistake here is using a custom string instead of the standard DefaultAuthenticationTypes.ApplicationCookie:

// Correct: Use the same AuthenticationType as your cookie setup
var identity = new ClaimsIdentity(yourClaimsCollection, DefaultAuthenticationTypes.ApplicationCookie);

// Then sign in correctly
HttpContext.GetOwinContext().Authentication.SignIn(
    new AuthenticationProperties { IsPersistent = rememberMe }, 
    identity);

Mismatched types mean OWIN won't recognize the cookie as a valid authentication token.

3. Fix Web.config Settings #

OWIN handles authentication independently of traditional ASP.NET forms auth, so make sure your web.config doesn't conflict:

• Set <authentication mode="None" /> to disable old forms auth:

  <system.web>
      <authentication mode="None" />
      <!-- Other settings -->
  </system.web>
  

• Check <httpCookies>: If your site isn't using HTTPS, set requireSSL="false" (otherwise the browser will reject the cookie):

  <system.web>
      <httpCookies httpOnlyCookies="true" requireSSL="false" />
  </system.web>
  

• Avoid conflicting session state configs: If using sessionState, ensure it's set to a mode that works with your deployment (InProc is fine for development).

4. Redirect After Login (Don't Return Directly) #

When you sign a user in, the authentication cookie is sent in the response header. If you return the Confirm view directly from your Login action, the current request's User object won't reflect the new identity—it's only loaded at the start of the request. Always redirect after sign-in:

[HttpPost]
public ActionResult Login(LoginViewModel model)
{
    // User validation logic here...

    // Create identity and sign in
    var identity = new ClaimsIdentity(claims, DefaultAuthenticationTypes.ApplicationCookie);
    HttpContext.GetOwinContext().Authentication.SignIn(identity);

    // Redirect to Confirm instead of returning the view
    return RedirectToAction("Confirm", "Account");
}

This triggers a new request where OWIN will read the cookie and set User.Identity.IsAuthenticated correctly.

5. Debug the Authentication Cookie #

Use your browser's dev tools (F12 > Application > Cookies) to check if the OWIN cookie exists:

• Look for the default cookie name: .AspNet.ApplicationCookie (or your custom name if you set it)
• Verify the cookie has a valid expiration date, correct path, and isn't marked as "Secure" if you're not using HTTPS
• If the cookie isn't present, your sign-in logic isn't generating it—double-check your ClaimsIdentity creation and SignIn call

6. Ensure Consistent OWIN Package Versions #

Mismatched NuGet package versions can cause silent failures. Make sure all OWIN-related packages (like Microsoft.Owin, Microsoft.Owin.Security.Cookies, Microsoft.Owin.Host.SystemWeb) are on the same major/minor version.

Start with these checks—middleware order and AuthenticationType matching are the two biggest culprits here. Let me know if you hit any roadblocks with specific code snippets!

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