RESTFull风格的.NET Core微服务前后端分离架构实现之四（认证授权）

前面我已经完成了一个完整的CRUD操作，并且通过了测试。这就是面向微服务的模块化开发模式，微服务模块之间的耦合性低，内部的内聚性高。其余的所有实际中的业务操作，都可以按照前面实现出来的功能，进行扩展。

要实现分布式的微服务架构，需要解决前端用户的认证授权问题。这里的前端用户，不一定是人，也可能是机器或者其他东西。分布式的微服务架构不适宜用session的解决方案来实现认证授权，注意这里我说的是不适宜，而不是不适用。所以我打算使用过滤器来横向切入，通过JWT的解决方案来实现我这个项目的认证授权需求。这也算是借用了Java里面的AOP的编程思想吧，出于实战的目的，这里我就不过多的解释技术细节了，不清楚的技术细节，就自行百度吧。

其实，如果是需要实现单点登录的话，也可以把认证授权这部分，独立出一个项目来做，单独部署。这样前端就可以先通过认证授权服务器来进行认证授权操作，通过之后，再分发到后端的微服务集群，进行业务操作。出于项目演示的简单性原则，这里我就把认证授权模块集成到一个项目中来实现了。

1、JwtUtil的实现

首先，需要安装JWT的程序包，这里就请自行安装吧，安装完成后的截图如下所示。

其次，在Utils文件夹中新建JwtUtil.cs类文件，代码如下图所示。

我就不展开源代码了，需要源代码的，请自行到github上下载。

这里需要解释一下，常量字符串secret是生成Token的密钥。我这里是把传入的id，认证授权的失效时间，通过secret进行加密。然后返回加密的Token字符串给前端，前端保存这个Token，以后需要业务操作的话，前端传递Token给后端，后端经过验证，决定是否放行该业务操作。这就是Token方式的大致描述，要想了解详细细节的话，还请自己查找JWT的资料查看。

2、过滤器的实现

首先，在Filters文件夹中建立AuthFilter.cs的过滤器类文件，代码如下图所示。

这里，我只是简单的实现了一个静态的验证方法，没有使用JWT的方式。然后，我在OnAuthorization方法中通过if语句，实现了一个简单的业务逻辑。简单来说，就是，只要在controller中的action上添加了[AllowAnonymous]这个注解，那过滤器就放行该操作，而不做下面的认证授权操作。代码如下图所示。

这样做的好处是，不需要认证授权的操作，比如说登录，则可以直接放行。

其次，在Startup.cs中，加入AuthFilter过滤器，代码如下图所示。

3、测试

对认证授权模块进行测试，需要在controller和repository中，实现一个getToken()方法，用来在前端获取Token进行测试。

我这个项目的认证授权的大致流程是这样的：前端登录系统、获取Token、返回前端保存Token、访问带有[AllowAnonymous]这个注解的服务接口（直接放行）、访问不带[AllowAnonymous]这个注解的服务接口（验证Token）。

这个getToken()方法，我就不传入用户名和密码参数进行验证了，这里我直接返回生成的Token，代码如下图所示。

注意这个getToken()服务接口，添加了[AllowAnonymous]这个注解。

接下来是在过滤器中修改Token验证的业务逻辑。

我这里用字符串1来表示验证通过，非1表示验证不通过。接下来是测试，先启动项目，首先是先获取Token，如下图所示。

接下来通过访问getUsers服务接口来测试认证授权是否正常运行，第一步是不带Token的访问。

可以看到，不带Token的访问，返回值是401，说明没有认证和授权，被阻止了，过滤器运行测试通过。

第二步是带有Token的访问。

可以看到，通过在Headers中加入Authorization的Token值，访问通过，可以正常获取到数据，说明通过认证授权，测试通过。

到此为止，认证授权模块的实现，就算是完成了，并且通过了测试。我这个项目架构的实现，也算是初步实现了，并且可以正常使用。在分布式的微服务构架模式中，通过Token的方式来实现认证授权，是现在的主流模式。并且这种方式，也不会受制于前端的技术，这就充分降低了前后端之间和认证授权模块的耦合度。这种方式实现的认证授权模块，完全可以独立成一个项目，单独部署，用来实现分布式微服务架构的单点登录。这样在性能方面，能够得到一个更大的提升。