OAuth2结合Microsoft.AspNetCore.Identity的REST API报错问题排查

1. 能否同时使用OAuth2与Microsoft.AspNetCore.Identity？ #

完全可以，这甚至是.NET生态中实现完整权限系统的推荐组合：

• Microsoft.AspNetCore.Identity负责核心的用户/角色存储、密码哈希、账户管理（注册、重置密码等）基础功能；
• OAuth2（常用JWT实现）负责令牌的发放、验证，适配REST API的无状态认证需求。

你当前遇到的重定向问题，是因为引入Identity后，默认的认证方案被设置为了Cookie认证（Identity默认配置），而你的API需要的是Bearer Token认证。当请求没有携带有效Cookie时，系统会触发Cookie认证的挑战逻辑——重定向到登录页，导致404。

解决重定向问题的关键配置 #

在Program.cs中明确指定认证方案优先级，并禁用JWT认证的重定向行为：

// 配置Identity（用户/角色存储）
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddRoles<IdentityRole>()
    .AddEntityFrameworkStores<AppDbContext>();

// 配置OAuth2（JWT）认证，并设置为默认方案
builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = builder.Configuration["Jwt:Issuer"],
        ValidAudience = builder.Configuration["Jwt:Audience"],
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]))
    };

    // 禁用重定向，API认证失败直接返回401
    options.Events = new JwtBearerEvents
    {
        OnChallenge = context =>
        {
            context.HandleResponse();
            context.Response.StatusCode = StatusCodes.Status401Unauthorized;
            context.Response.ContentType = "application/json";
            return context.Response.WriteAsync(System.Text.Json.JsonSerializer.Serialize(new { message = "未授权访问" }));
        }
    };
});

// 别忘了添加授权中间件
builder.Services.AddAuthorization();

// 中间件顺序要正确：先认证，再授权
app.UseAuthentication();
app.UseAuthorization();

如果不想全局设置默认方案，也可以在控制器的[Authorize]特性中指定Bearer方案：

[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
public IActionResult GetProtectedData()
{
    // 接口逻辑
}

2. 是否更适合手动创建存储用户和角色的数据库表？ #

不推荐手动建表，原因如下：

• Identity已经提供了一套经过验证的表结构（如AspNetUsers、AspNetRoles、AspNetUserRoles等），包含了用户认证、角色关联所需的所有字段（密码哈希、安全戳、邮箱确认状态等），手动建表容易遗漏关键字段或设置错误的字段类型，导致Identity功能失效。
• 通过继承IdentityDbContext，可以自动生成这些表，还能轻松扩展用户/角色的自定义字段（比如给用户加NickName、Phone）：

  public class AppUser : IdentityUser
  {
      public string NickName { get; set; }
  }
  
  public class AppDbContext : IdentityDbContext<AppUser>
  {
      public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
      {
      }
  }
  

• 只有当你的业务需求完全不兼容Identity的表结构（比如已有一套 legacy 用户系统）时，才需要考虑手动实现用户存储，否则优先使用Identity的内置方案。

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