创建ClaimsIdentity后重定向，User.Identity.IsAuthenticated仍为false求助

这种情况我之前排查过好多次，大概率是OWIN认证上下文同步或者登录操作的细节没处理到位。给你梳理几个核心排查点和解决办法：

1. 确保用OWIN的AuthenticationManager完成登录，而非手动修改ClaimsPrincipal #

你提到手动把身份添加到ClaimsPrincipal.Current.Identities，这其实是无效的——因为ClaimsPrincipal.Current是当前请求上下文的临时对象，请求结束后就会被重置，重定向后的新请求根本拿不到这个修改。

正确的做法是通过OWIN上下文的AuthenticationManager执行登录操作，它会自动将身份持久化到认证票据（比如Cookie）中：

// 获取OWIN认证管理器
var authManager = HttpContext.Current.GetOwinContext().Authentication;
// 执行登录，同时可以配置是否持久化Cookie
authManager.SignIn(new AuthenticationProperties { IsPersistent = false }, yourClaimsIdentity);

2. 必须给ClaimsIdentity设置有效的AuthenticationType #

创建ClaimsIdentity时，一定要指定与你Startup中配置的认证Scheme匹配的AuthenticationType，否则ASP.NET无法识别这个身份的合法性，IsAuthenticated会直接返回false：

// 比如用Cookie认证的默认Type
using Microsoft.Owin.Security.Cookies;

var identity = new ClaimsIdentity(yourClaimsCollection, CookieAuthenticationDefaults.AuthenticationType);

3. 检查Startup.cs中的认证中间件配置顺序 #

认证中间件必须放在WebApi/Mvc等业务中间件之前，否则请求到达业务逻辑时，认证流程还没执行，User.Identity自然是未认证状态：

public void Configuration(IAppBuilder app)
{
    // 先配置Cookie认证中间件
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
        LoginPath = new PathString("/Account/Login")
    });

    // 再配置业务中间件
    app.UseWebApi(config);
    // 或者 app.UseMvc(...);
}

4. 验证重定向请求是否携带认证Cookie #

打开浏览器开发者工具（F12），查看Display页面的请求头，确认是否存在.AspNet.Cookies（默认名称）的Cookie。如果没有，说明登录操作没有成功写入Cookie，回头检查前面的SignIn代码和中间件配置。

5. 优先使用Controller的User属性，而非ClaimsPrincipal.Current #

ClaimsPrincipal.Current在某些线程切换或上下文同步场景下会出现不一致，在Controller中直接用User属性更可靠——它直接绑定当前请求的OWIN认证上下文。

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