微服务做用户认证授权一直是难点，随着OAuth2.0的密码模式被废除，更是难上加难。今天胖哥群里的一位群友在搭建用户认证授权系统的时候遇到了一些棘手的问题，让胖哥觉得是时候分享一些想法了。两种思路微服务的认证授权一般有两种思路：所有的认证授权都交由一个独立的用户认证授权服务器来处理，它只负责颁发token，然后网关只负责将请求转发到每个微服务模块。服务的每个模块都会自行验证Token。另一种是网关不仅承担流量转发的作用，还承担认证授权过程。当前请求的认证信息由网关中继到下游服务器。第一种很简单，我在多个微服务项目中都是这样设计的。如果您以前从未设计过它，我实际上建议您以这种方式进行。只需要搭建一个负责管理用户和角色权限的服务器，其他微服务模块作为资源服务器。三户模型系统足以应对各种场景。第二种结合了OAuth2体系。网关不仅承担流量转发的功能，还在网关层处理鉴权和授权，token会中转给下游服务。在这种模式下，需要构建一个UAA（UserAccountAndAuthentication）服务。它非常灵活，它可以管理用户，也可以让受信任的客户自己管理用户。它只负责对客户端进行认证（不同于用户认证）和对客户端进行授权。目前使用OAuth2构建微服务安全体系的，都是采用这种方式。接下来分享一下我在第二条思路上的成果。SpringCloudGateway结合OAuth2提供UAA服务的技术有：SpringCloudGateway、SpringAuthorizationServer、SpringSecurity5.0、OAuth2Client、OIDC1.0总体思路，UAA服务端自然是由SpringAuthorizationServer来承担。它负责整个用户的管理。当然也可以单独单独一个用户服务器，但是UAA需要通过SpringCloudOpenFeign与用户服务通信；此外，它还是一个OAuth2授权服务器，管理OAuth2客户端，处理OAuth2授权。重要的一点来了，网关需要作为OAuth2客户端向UAA服务器注册，并充当OAuth2客户端。微服务应用当UserAgent（浏览器、APP）通过网关请求资源时：上面执行了一个标准的OAuth2授权码流程，SpringCloudGateway会引导用户到UAA服务器的登录界面进行登录。终端后用户登录，进行授权确认，注意F12的链接。用户确认后，用户检查授权并确认，资源访问成功，调用的链接也检查。提交资源访问授权确认成功后，再次跳转到OAuth2授权码登录流程，最终获取到资源。我们看一下最终的/res/foo请求的细节，它居然在没有携带Token的情况下拿到了用户的所有权限。这都归功于网关令牌中继，前端应用程序在其中很好地屏蔽了JWT令牌。如果有多个Gateway节点和UAA节点，可能需要结合SpringSession实现分布式Session，对部分客户端信息和用户信息进行分布式管理。总结通过以上流程的介绍，动手能力强的小伙伴应该可以实现相关功能了。
