aspnet core 2.1中使用jwt从原理到精通二

时间 2019-11-24

标签 aspnet core 2.1 使用 jwt 原理精通繁體版

原文原文链接

目录html

在aspnet core中，自定义jwt管道验证；
在aspnet core中,自定义策略验证CommonAuthorizeHandler : AuthorizationHandler<CommonAuthorize>

学有所得数据库

如何在项目中实现自定义的复杂jwt验证
如何经过中间件形式和自定义策略形式实现自定义jwt验证

在aspnet core中，自定义jwt管道验证

有了上一节的内容做为基础，那这点也是很是容易的，关键点在中间件，只是把上一级在测试类中的自定义验证放到中间件中来便可，json

不过须要注意：中间件的位置很重要，只有它后面的管道才会收到影响；api

那咱们先建一个自定义中间件类：（中间件的详细内容这里就不讲了，你们能够参考官网和其余博文）缓存

/// <summary>
    /// 自定义受权中间件
    /// </summary>
    public class JwtCustomerAuthorizeMiddleware
    {
        private readonly RequestDelegate next;

        public JwtCustomerAuthorizeMiddleware(RequestDelegate next, string secret, List<string> anonymousPathList)
        {
            #region   设置自定义jwt 的秘钥
            if(!string.IsNullOrEmpty(secret))
            {
                TokenContext.securityKey = secret;
            }
            #endregion
            this.next = next;
            UserContext.AllowAnonymousPathList.AddRange(anonymousPathList);
        }

        public async Task Invoke(HttpContext context, UserContext userContext,IOptions<JwtOption> optionContainer)
        {
            if (userContext.IsAllowAnonymous(context.Request.Path))
            {
                await next(context);
                return;
            }

            var option = optionContainer.Value;

            #region 身份验证，并设置用户Ruser值
 
            var result = context.Request.Headers.TryGetValue("Authorization", out StringValues authStr);
            if (!result || string.IsNullOrEmpty(authStr.ToString()))
            {
                throw new UnauthorizedAccessException("未受权");
            }
            result = TokenContext.Validate(authStr.ToString().Substring("Bearer ".Length).Trim(), payLoad =>
            {
                var success = true;
                //能够添加一些自定义验证，用法参照测试用例
                //验证是否包含aud 并等于 roberAudience
                success = success && payLoad["aud"]?.ToString() == option.Audience;
                if (success)
                {
                    //设置Ruse值,把user信息放在payLoad中，（在获取jwt的时候把当前用户存放在payLoad的ruser键中）
                    //若是用户信息比较多，建议放在缓存中，payLoad中存放缓存的Key值
                    userContext.TryInit(payLoad["ruser"]?.ToString());
                }
                return success;
            });
            if (!result)
            {
                throw new UnauthorizedAccessException("未受权");
            }

            #endregion
            #region 权限验证
            if (!userContext.Authorize(context.Request.Path))
            {
                throw new UnauthorizedAccessException("未受权");
            }
            #endregion

            await next(context);
        }
    }

上面这个中间件中有个UserContext上线文，这个类主要管理当前用户信息和权限,其余信息暂时无论；咱们先看一下这个中间件的验证流程如何：app

该中间件主要是针对访问的路径进行验证，固然你也能够针对其余信息进行验证，好比（控制器名称，动做名称，等）async

检查当前url是否能够匿名访问，若是能够就直接经过，不作验证了；若是不是能够匿名访问的路径，那就继续
获取当前http头部携带的jwt（存放在头部的 Authorization中）；
使用上一节的讲的TokenContext作必须的验证和自定义复杂验证；
获取当前访问用户信息，咱们把用户的基本信息放在payLoad["ruser"]中，请看代码如何操做
到这里为止，都是作的身份验证，代表你是一个有身份的的人；接下来是作权限验证，你是一个有身份的人，并不表明你是一个随便处处访问的人；你能访问哪些url或者action，就要获得权限验证的承认
咱们把权限验证放到 userContext.Authorize方法中（这里怎么操做，这里就不深刻讲解，基本原理是从数据库或者缓存中获取当前用户对应的权限列表，也就是url列表，进行对比）;

自定义中间件使用jwt验证就这些内容，是否是感受很清晰，很简单，有木有；ide

中间已经完成了，那接下来咱们来使用它，咱们再startup中的Configure方法中添加以下代码性能

app.UseMiddleware<JwtCustomerAuthorizeMiddleware>(Configuration["JwtOption:SecurityKey"], new List<string>() { "/api/values/getjwt","/" });测试

固然上面可匿名访问的url也能够定义在appsetting.json文件中，能够自行尝试

如何经过自定义策略形式实现自定义jwt验证

建立自定义策略的详细介绍能够参考官网，这里就不详细介绍，

首先咱们上代码，建立自定义策略很是重要的两个类，以下：

 public class CommonAuthorizeHandler : AuthorizationHandler<CommonAuthorize>
    {
        /// <summary>
        /// 经常使用自定义验证策略，模仿自定义中间件JwtCustomerauthorizeMiddleware的验证范围
        /// </summary>
        /// <param name="context"></param>
        /// <param name="requirement"></param>
        /// <returns></returns>
        protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, CommonAuthorize requirement)
        {
            var httpContext = (context.Resource as AuthorizationFilterContext).HttpContext;
            var userContext = httpContext.RequestServices.GetService(typeof(UserContext)) as UserContext;

            var jwtOption = (httpContext.RequestServices.GetService(typeof(IOptions<JwtOption>)) as IOptions<JwtOption>).Value;

            #region 身份验证，并设置用户Ruser值

            var result = httpContext.Request.Headers.TryGetValue("Authorization", out StringValues authStr);
            if (!result || string.IsNullOrEmpty(authStr.ToString()))
            {
                return Task.CompletedTask;
            }
            result = TokenContext.Validate(authStr.ToString().Substring("Bearer ".Length).Trim(), payLoad =>
            {
                var success = true;
                //能够添加一些自定义验证，用法参照测试用例
                //验证是否包含aud 并等于 roberAudience
                success = success && payLoad["aud"]?.ToString() == jwtOption.Audience;
                if (success)
                {
                    //设置Ruse值,把user信息放在payLoad中，（在获取jwt的时候把当前用户存放在payLoad的ruser键中）
                    //若是用户信息比较多，建议放在缓存中，payLoad中存放缓存的Key值
                    userContext.TryInit(payLoad["ruser"]?.ToString());
                }
                return success;
            });
            if (!result)
            {
                return Task.CompletedTask;
            }

            #endregion
            #region 权限验证
            if (!userContext.Authorize(httpContext.Request.Path))
            {
                return Task.CompletedTask;
            }
            #endregion

            context.Succeed(requirement);
            return Task.CompletedTask;
        }
    }
    public class CommonAuthorize: IAuthorizationRequirement
    {

    }

其中两个重要的类是哪两个呢？他们的做用又是什么呢？

CommonAuthorize: IAuthorizationRequirement，至于取什么名字，本身定义，但必须继承IAuthorizationRequirement，这类主要是承载一些初始化值，让后传递到Handler中去，给验证作逻辑运算提供一些可靠的信息；我这里是空的；本身根据自身状况本身定义适当的属性做为初始数据的承载容器；

```
CommonAuthorizeHandler : AuthorizationHandler<CommonAuthorize>这个是重点，承载了验证的逻辑运算
须要重写override Task HandleRequirementAsync方法，全部的逻辑都在该方法中，他的主要逻辑和上面的自定义中间件很类似，只少了上面的第一步；验证流程以下：
```
1. 获取当前http头部携带的jwt（存放在头部的 Authorization中）；
2. 使用上一节的讲的TokenContext作必须的验证和自定义复杂验证；
3. 获取当前访问用户信息，咱们把用户的基本信息放在payLoad["ruser"中，请看代码如何操做
4. 到这里为止，都是作的身份验证，代表你是一个有身份的的人；接下来是作权限验证，你是一个有身份的人，并不表明你是一个随便处处访问的人；你能访问哪些url或者action，就要获得权限验证的承认
5. 咱们把权限验证放到 userContext.Authorize方法中（这里怎么操做，这里就不深刻讲解，基本原理是从数据库或者缓存中获取当前用户对应的权限列表，也就是url列表，进行对比）;
```
context.Succeed(requirement);是验证成功，若是没有这个，就默认验证失败
```
  由于UserContext把负责了权限验证，因此不会把流程搞得感受很乱，而且能够重用，至于用那种形式验证也很容易切换
是否是很简单，和自定义管道验证的的代码几乎如出一辙，

如何使用自定义定义策略呢？

在startup类中的ConfigureServices中加入以下代码：

services.AddAuthorization(option =>
            {
                

                #region 自定义验证策略
                option.AddPolicy("common", policy => policy.Requirements.Add(new CommonAuthorize()));
                #endregion


            }).AddAuthentication(option =>
            {
                option.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
            }).AddJwtBearer(option =>
            {
                if (!string.IsNullOrEmpty(config["JwtOption:SecurityKey"]))
                {
                    TokenContext.securityKey = config["JwtOption:SecurityKey"];
                }
                //设置须要验证的项目
                option.TokenValidationParameters = new TokenValidationParameters
                {
                   
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(TokenContext.securityKey))//拿到SecurityKey
                };
            });

            //自定义策略IOC添加
            
            services.AddSingleton<IAuthorizationHandler, CommonAuthorizeHandler>();

以上代码主要分3个部分
一、添加上面自定义的策略，并取名；
二、设置秘钥，这个秘钥就是上一节中生成jwt的秘钥，必需要要同样，不然是签名不正确
三、注入上面创建的一个重要类CommonAuthorizeHandler，如上面代码

在startup类中的Configure中添加 app.UseAuthentication();
在须要验证的Controller或者Action中加上[Authorize(Policy = "common")]属性，看下图：

到此为止你就可使用自定义策略的验证了；

使用管道和自定义策略两种形式进行验证有什么区别呢?

从效果上看都是同样的，稍微有点区别

使用管道的方式，感受方便点，清晰点
使用自定义策略的方式，效率稍微高一点，毕竟不是全部的请求都会进行是否能够匿名访问运算和创建管道的消耗，只有加入Authorize属性的Controller和Action的才会进入；固然这点损耗能够忽略不计，看本身的喜爱；

至于你喜欢那种，就使用哪一种吧，性能能够忽略不计；

无论使用哪一种方式使用jwt做为身份和权限验证是否是很简单，关键这里也把权限验证的逻辑抽出来了，这样代码就更清晰明了了；

至于Authorize的属性形式，还有不少其余的策略，好比用户、申明，角色等，可查看官网https://docs.microsoft.com/zh-cn/aspnet/core/security/authorization/?view=aspnetcore-2.0

下一章将讲解用户，申明，角色的验证，并这些怎么在自定义的验证中实现，以便你们对他有个清晰的对比