ASP.NET Core 使用 Claim 认证详解
微软在早期 .NET Framework 时代,针对 ASP.NET 的用户登录身份认证,提供了 Forms 认证实现方案。后来在推出 ASP.NET Core 之后,采用 Claim 认证替代了 Forms 认证,两者本质上都是基于 Cookie 加解密的认证方式,学习和使用起来非常简单,比较适合在小型项目中使用,主要是方便。
假设我们现在已经创建好了一个基于 .NET5 模型-视图-控制器 的 ASP.NET Core Web 应用 (这里就不介绍创建过程了),下面我就基于 .NET5 网站,介绍一下 Claim 认证的具体实现方式:
1 修改 appsettings.json 配置文件,增加有关 Cookie 的相关配置
在实际开发场景中,我们一般将 Cookie 相关信息进行配置,所以我们增加以下配置信息:
{
// 这里采用了两级嵌套的 json 配置方式
"web": {
// 用户未登录时,自动跳转的目标路由地址
"loginUrl": "/Home/Login",
// Cookie 的名字
"cookieName": "UserAuth",
// Cookie 保存的路径,这里保存在根路径
"cookiePath": "/",
// Cookie 的所属的域名
"cookieDomain": ".demo.com"
}
}
其实上面的 json 配置中, Cookie 的保存路径,所属域名,都可以配置为空,这样不影响 Claim 认证的实现。
但是有一种情况例外,那就是万恶的 IE 浏览器。对于 IE 浏览器来说,上面的 json 配置中,必须配置好 Cookie 的保存路径和域名,否则无法生成 Cookie,无法实现 Claim 认证。
如果你实施的项目不考虑 IE 浏览器的话,那就很幸运了。但是目前国内的很多银行、政府、国企,未来很长一段时间仍然还在使用 IE 浏览器,所以有时候还得被迫考虑 IE 浏览器。
2 修改 Startup.cs 文件,增加 Claim 认证支持
需要修改两个地方 ConfigureServices 方法 和 Configure方法
在 ConfigureServices 方法 中添加 Cookie 认证方式,在 Configure方法 中使用认证和授权。
注意:Configure 方法每行代码的顺序位置很重要,新增加的两行代码(app.UseAuthentication 和 app.UseAuthorization 必须在 app.UseRouting 之后,app.UseEndpoints 之前)
public void ConfigureServices(IServiceCollection services, IConfiguration Config)
{
services.AddControllersWithViews();
//添加 Cookie 认证方式
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
{
//从配置节中读取配置的 Cookie 信息
options.LoginPath = Config["web:loginUrl"];
options.Cookie.Name = Config["web:cookieName"];
options.Cookie.Path = Config["web:cookiePath"];
options.Cookie.Domain = Config["web:cookieDomain"];
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseStaticFiles();
app.UseRouting();
//使用认证和授权
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Web}/{action=Index}");
});
}
3 在相关 Controller 中的 Action 方法添加 Claim 认证的代码
假设我们在登录页面,输入了用户名密码,提交到后台的 Home/Login 中,该 Action 已经在数据库中验证了用户名和密码的正确性,接下来就要生成 Claim 认证的 Cookie,代码如下:
public IActionResult Login(string name, string pwd)
{
//......此处省略了去数据库验证用户名和密码,以及获取用户的权限的相关代码
//可以添加额外的信息存储在cookie中
//这里把从数据库中获取的【用户角色】和【权限码】进行存储
var claims = new[] { new Claim("Power", power), new Claim("Role", role) };
//这里存储【用户名】
//这样后面就可以通过 User.Identity.Name 获取到用户名了
GenericIdentity gi = new GenericIdentity(name);
ClaimsIdentity ci = new ClaimsIdentity(gi, claims,
CookieAuthenticationDefaults.AuthenticationScheme, "", "");
ClaimsPrincipal cp = new ClaimsPrincipal(ci);
Task.Run(async () =>
{
//生成 Cookie 并保存到硬盘中,指定 Cookie 的过期时间
await HttpContext.SignInAsync(
CookieAuthenticationDefaults.AuthenticationScheme,cp, new AuthenticationProperties()
{
IsPersistent = true,
ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(60),
AllowRefresh = true
});
}).Wait();
return Content("login success");
}
前端通过 Ajax 调用后端登录方法后,如果成功,然后跳转到网站主页即可。
4 控制 Controller 和 Action 的访问
我们可以通过在 Controller 上或 Action 上增加 [Authorize] 标记 或 [AllowAnonymous] 标记,来控制用户对具体 Controller 或 Action 的访问,这跟以前的 Forms 认证的控制方式一模一样。
[Authorize] 标记:
表示必须拥有 Claim 的 Cookie 才能访问,否则就会跳转到指定的页面,我们一般指定跳转到登录页面。可以放到 Controller 或 Action 上。如果该标记添加到 Controller 上,则该 Controller 下的所有 Action 都会验证是否拥有 Claim 的 Cookie。
[AllowAnonymous] 标记:
表示允许匿名用户访问,没有登录也可以访问,也就是不需要 Claim 的 Cookie 就可以访问。可以放到 Controller 或 Action 上。通常的使用场景是:在 Controller 上放了 [Authorize] 之后,在该 Controller 下具体的一小部分 Action 上放 [AllowAnonymous] 标记。这样就保证 Controller 下只有一小部分 Action 允许未登录用户访问,其它的 Action 必须用户登录后才能访问。
5 获取 Claim 的 Cookie 中的信息以及退出登录
在上面第 3 步中,我们通过 GenericIdentity gi = new GenericIdentity(name) 这行代码存储登录的用户名,因此我们可以通过 User.Identity.Name 获取到登录的用户名。
下面列出获取 Cookie 中存储的其它信息,比如上面存储的 Power 和 Role
[Authorize]
public IActionResult Display()
{
StringBuilder sb = new StringBuilder();
// 遍历获取所有的存储信息
foreach (var cl in HttpContext.User.Claims)
{
sb.AppendLine($"{cl.Type}|{cl.Value}");
}
// 通过便捷的方式获取登录的用户名
sb.AppendLine(User.Identity.Name);
// 想要获取到具体的一项存储信息,比如仅仅想获取权限码和角色
sb.AppendLine(User.FindFirstValue("Power"));
sb.AppendLine(User.FindFirstValue("Role"));
return Content(sb.ToString());
}
如果想要用户退出登录,销毁 Cookie 的话,可以采用以下代码:
public IActionResult LogOut()
{
if (User.Identity.IsAuthenticated)
{
Task.Run(async () => { await HttpContext.SignOutAsync(); }).Wait();
}
//销毁 Claim 的 Cookie 后,可以跳转到登录页面
return RedirectToAction("Index", "Web");
}
6 优缺点闲谈
到此为止,ASP.NET Core 网站使用 Claim 认证,实现用户登录,访问时进行身份验证方案,已经介绍完了。如果你想要快速搭建轻量级网站应用的话,使用 Claim 认证方式是一种非常方便快速的方案。
但是不建议在大中型项目中使用,还是采用主流的 token + redis 的方案实现用户登录认证比较好,原因如下:
- 后续项目肯定会涉及到各个系统之间的统一认证对接,以及与第三方的单点登录对接,这种情景使用 token + redis 的方案比较灵活简单,采用 Cookie 的实现方式比较麻烦。
- 对于用户请求负载均衡分发的场景,token + redis 的方案是非常好的方案,因为其天然保证所有请求都是无状态的,不需要在负载均衡服务器上配置会话保持,这样负载均衡服务器就可以根据每台应用服务器的负载状况,随意使用任何负载请求分发策略。
- 对于负载均衡来说, Claim 认证方案就不够灵活了,因为其 Cookie 只能在具体的服务器上进行加解密,从而识别登录用户。如果新的请求被负载均衡服务器分发到另一台应用服务器的话,那么就无法解密 Cookie 从而导致需要频繁重新登录,无法使用网站。只有在负载均衡服务器上配置会话保持,从而实现在一定的时间内将来自同一 ip 的请求分发到固定的应用服务器上,才能解决问题。(具体在各个不同的服务器之间,如何实现 Claim 的 Cookie 采用统一的加解密算法,我个人没有研究过。其实也没必要研究了,因为我们大部分情况下都会使用目前比较流行的 token + redis 方案,能够轻松解决任何问题)