看起来你的代码思路是对的，但有几个细节问题可能导致登录不生效，还有角色授权的潜在坑。我帮你一步步梳理和修复：

1. 最致命的问题：用索引读取Claims太脆弱 #

你现在用tokenS.Claims.ElementAt(1)来获取用户信息，JWT的Claims顺序是不固定的！如果JWT里的Claims顺序发生变化（比如新增了一个claim），你的代码就会读取错误的值，甚至直接崩溃。必须通过Claim类型来安全获取：

// 替换原来的索引读取方式，用ClaimType或自定义claim名称查找
var emailClaim = tokenS.Claims.FirstOrDefault(c => 
    c.Type == ClaimTypes.Email || c.Type.Equals("email", StringComparison.OrdinalIgnoreCase));
if (emailClaim == null)
{
    return BadRequest("无效的JWT Token：缺少邮箱Claim");
}
var userEmail = emailClaim.Value;

2. 控制器实例字段Data的生命周期问题 #

你用Data.accessToken和Data.EMAIL存储数据，但ASP.NET Core的控制器是每次请求都创建新实例的！这意味着你在SignIn后重定向，新请求的控制器里Data.accessToken又会变回null，导致重复执行登录逻辑，甚至覆盖认证状态。

建议改用Session或认证Cookie本身来存储用户信息：

// 存储邮箱到Session
HttpContext.Session.SetString("UserEmail", userEmail);

// 后续读取时
var currentUserEmail = HttpContext.Session.GetString("UserEmail");

3. SignIn后的重定向优化 #

你现在直接Redirect("/")，虽然没问题，但更稳妥的是重定向到当前Action（RedirectToAction(nameof(Index))），确保认证Cookie完全写入响应后再加载页面。

4. 完善SignInAsync的配置 #

给AuthenticationProperties加上明确的过期时间，增强持久化效果，同时确保ClaimsIdentity的Scheme和Cookie认证Scheme一致：

var claims = new List<Claim> 
{ 
    new Claim(ClaimTypes.Name, userEmail), 
    new Claim("FullName", userEmail), // 如果JWT里有FullName Claim，记得从Token里读取，不要复用邮箱
    new Claim(ClaimTypes.Role, "Admin"), 
    // 可选：把JWT里的其他Claims也同步过来，比如tokenS.Claims.Where(c => c.Type != ClaimTypes.Name).ToList()
}; 

var claimsIdentity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme); 
var authProperties = new AuthenticationProperties 
{ 
    IsPersistent = true, 
    ExpiresUtc = DateTimeOffset.UtcNow.AddDays(7), // 设置7天过期
    SlidingExpiration = true // 滑动过期，用户活跃时自动延长有效期
};

await HttpContext.SignInAsync(
    CookieAuthenticationDefaults.AuthenticationScheme, 
    new ClaimsPrincipal(claimsIdentity), 
    authProperties); 

return RedirectToAction(nameof(Index));

5. 检查Startup中的中间件配置 #

这是很多人忽略的点：认证和授权中间件的顺序必须正确，否则登录状态不会被后续请求识别：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // ... 其他中间件（比如ExceptionHandler、StaticFiles）

    app.UseRouting();

    // 必须在UseRouting之后，UseEndpoints之前
    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

同时要确保Cookie认证的Scheme配置正确：

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();

    services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
        .AddCookie(options =>
        {
            options.Cookie.Name = ".YourApp.Auth"; // 自定义Cookie名称
            options.LoginPath = "/Authentication/signin";
            options.ExpireTimeSpan = TimeSpan.FromDays(7);
            options.SlidingExpiration = true;
        });
}

6. 角色授权的验证 #

要让Admin角色生效，只需在需要授权的Action上添加特性：

[Authorize(Roles = "Admin")]
public IActionResult AdminOnlyPage()
{
    return View();
}

最后排查步骤 #

1. 打开浏览器开发者工具，查看Application -> Cookies，确认登录后是否生成了对应的认证Cookie
2. 在重定向后的页面中，打印User.Identity.IsAuthenticated和User.Claims，检查是否包含你的Admin角色
3. 如果还是不行，尝试清除浏览器缓存和Cookie，重新测试

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