1、前言

  这块儿当时在IdentityServer4和JWT之间犹豫了一下,后来考虑到现状,出于3个原因,暂时放弃了IdentityServer4选择了JWT:

(1)目前这个前端框架更适配JWT;

(2)前后端分离的项目,如果上IdentityServer4,还要折腾点儿工作,比如前端配置、多余的回调等;

(3)跨度太大,团队、系统、历史数据接入都是问题,解决是可以解决,但时间有限,留待后续吧;

  当然,只是暂时放弃,理想中的最佳实践还是IdentityServer4做统一鉴权的。

2、JWT认证实现

(1)Common项目下定义JWTConfig配置对象



 

 (2)系统配置文件中增加JWT参数配置



 

 

 此处配置与(1)中的配置对象是对应的。

 

(3)JWT处理程序及相关服务注册
1 services.Configure<JWTConfig>(Configuration.GetSection("JWT")); 2 var
jwtConfig = Configuration.GetSection("JWT").Get<JWTConfig>(); 3
services.AddAuthentication(options => 4 { 5 options.DefaultAuthenticateScheme
= JwtBearerDefaults.AuthenticationScheme; 6 options.DefaultChallengeScheme =
JwtBearerDefaults.AuthenticationScheme; 7 }) 8 .AddJwtBearer(options => 9 {
10 options.TokenValidationParameters = new TokenValidationParameters 11 { 12
ValidateIssuer =true, 13 ValidIssuer = jwtConfig.Issuer, 14
ValidateIssuerSigningKey =true, 15 IssuerSigningKey = new
SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtConfig.SymmetricSecurityKey)),16
ValidateAudience =false, 17 ValidateLifetime = true, 18 ClockSkew =
TimeSpan.FromMinutes(5) 19 }; 20 options.Events = new JwtBearerEvents 21 { 22
OnTokenValidated = context => 23 { 24 var userContext =
context.HttpContext.RequestServices.GetService<UserContext>(); 25 var claims =
context.Principal.Claims; 26 userContext.ID = long.Parse(claims.First(x =>
x.Type == JwtRegisteredClaimNames.Sub).Value); 27 userContext.Account =
claims.First(x => x.Type == ClaimTypes.NameIdentifier).Value; 28
userContext.Name = claims.First(x => x.Type == ClaimTypes.Name).Value; 29
userContext.Email = claims.First(x => x.Type ==
JwtRegisteredClaimNames.Email).Value; 30 userContext.RoleId = claims.First(x =>
x.Type == ClaimTypes.Role).Value; 31 32 return Task.CompletedTask; 33 }34 }; 35
});36 JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
 


   上述代码中注意红色那部分Token验证成功的事件注册,其目的是认证成功之后,从JWT中取出必要信息构建当前用户上下文,这个上下文信息非常重要,但凡涉及到需要获取当前用户相关信息的部分,都要依赖它,后续文章中对应部分还会提及。

(4)登录并写入Token
1 /// <summary> 2 /// 登录 3 /// </summary> 4 /// <param
name="userDto"></param> 5 /// <returns></returns> 6 [AllowAnonymous] 7
[HttpPost("login")] 8 public async Task<IActionResult>
Login([FromBody]SysUserDto userDto) 9 { 10 var validateResult = await
_accountService.ValidateCredentials(userDto.Account, userDto.Password);11 if (!
validateResult.Item1)12 { 13 return new NotFoundObjectResult("用户名或密码错误"); 14 }
15 16 var user = validateResult.Item2; 17 var claims = new Claim[] 18 { 19 new
Claim(ClaimTypes.NameIdentifier, user.Account),20 new Claim(ClaimTypes.Name,
user.Name),21 new Claim(JwtRegisteredClaimNames.Email, user.Email), 22 new
Claim(JwtRegisteredClaimNames.Sub, user.ID.ToString()),23 new
Claim(ClaimTypes.Role, user.RoleId)24 }; 25 26 var key = new
SymmetricSecurityKey(Encoding.UTF8.GetBytes(_jwtConfig.SymmetricSecurityKey));27
28 var token = new JwtSecurityToken( 29 issuer: _jwtConfig.Issuer, 30 audience:
null, 31 claims: claims, 32 notBefore: DateTime.Now, 33 expires:
DateTime.Now.AddHours(2), 34 signingCredentials: new SigningCredentials(key,
SecurityAlgorithms.HmacSha256)35 ); 36 37 var jwtToken = new
JwtSecurityTokenHandler().WriteToken(token);38 39 return new JsonResult(new {
token = jwtToken }); 40 }
 (5)前端Token状态保存


  一般来讲,在后端登录成功返回前端之后,前端需要保存此token以保持状态,否则一刷新全完蛋,那我们来看看前端怎么实现。由于前端项目引入了Vuex来保持状态,那api调用、状态操作自然就放在store中,我们来看看登录对应的store。打开前端源码,找到user这个store:



 

 

   我们看到,登录完毕,调用SET_TOKEN这个mutation提交token状态变更保存Token,这个mutation及其背后的state如下如下:



 

 同时,在登录action中,登录成功之后,我们还发现了一行代码:



 

   此setToken引自前端工具类,auth.js,代码如下:
1 import Cookies from 'js-cookie' 2 3 const TokenKey = 'ngcc_mis_token' 4
5 export function getToken() { 6 return Cookies.get(TokenKey) 7 } 8 9 export
function setToken(token) { 10 return Cookies.set(TokenKey, token) 11 } 12 13
exportfunction removeToken() { 14 return Cookies.remove(TokenKey) 15 }

  至此我们明白了前端的机制,把token写入Vuex状态的同时,再写入cookie。那这里问一句,只写入Vuex状态,行不行呢?不行,因为浏览器一刷新,所有前端对象就会销毁,包括Vuex对象,这样会导致前端丢失会话。同时,我们再扩展深入下,假如这里我们要做点单登录,不借助IdentityServer4这种统一认证平台的话,怎么做呢?其实很简单,这里写入cookie改为写入localstoage这种浏览器中可以跨域共享的存储就可以了。

3、总结

  以上就是系统认证的实现,大家摸清楚各种认证方案、优缺点、特点,多深入源码、机制,遇到问题自然会手到擒来。
SET_TOKEN