SpringCloud 微服务认证授权方案（图文版）

1.微服务授权面临哪些问题

在微服务架构下有很多的服务，每个微应用都需要对访问进行认证检查和权限控制，客户端发起一个请求需要考虑如何让用户的认证状态通知到所有的微服务中，尤其是请求来源于多种客户端如浏览器，移动端，三方程序，服务之间访问时，微服务的授权变得更加麻烦，再加上本地Session在微服务(集群/分布式)环境中存在Session不同步的问题，所以我们微服务授权是非常非常复杂的。

Session不同步问题如图：

2.微服务常见认证方案

2.1.CAS单点登录

CAS是一种基于Cookie实现的单点登录方案，页是一个比较老的解决方案，是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，它分为 CAS Server端和CAS Client端，Server端负责用户的登录流程，Client端需要整合到各个系统中，它的登录流程如下：

系统A的访问流程：

• 浏览器请求系统A，系统A检查到没有登录，重定向到认证服务，并且携带参数service，这个参数的作用是在认证中心认证通过之后会再跳回系统A的重定向地址

• 请求跳转到认证中心，认证中心接收到请求，返回登录页面，用户提交登录信息
• 认证中心执行登录逻辑，认证成功，生成ticket（ST）和 TGC，认证中心会将TGC写到浏览器的cookie，有这个东西说明用户登录过，通过TGC可以找到TGT
• 然后认证中心将请求再重定向到系统A(根据之间的service参数回调地址)，并且携带一个ticket参数
• 请求跳转回了系统A，系统A得到ticket，向认证中心发起请求校验ticket的合法性

• 认证中心验证ticket通过，向client返回对应的用户信息

• 浏览器(同一个浏览器)访问另外一个客户端系统B，系统B检查到没有登录，请求重定向到认证中心

• 由于浏览器在访问系统A的时候已经到了登录，cookie中有TGC,所以认证中心可以获取到TGC找到对应的TGT
• 认证中心根据cookie中的TGC找到TGT，代表用户登录过，于是创建ticket,并重定向请求到系统B，带着参数ticket
• 系统B接收到请求，拿着ticket去认证中心校验Ticket

• 认证中心ticket校验通过，返回用户信息

2.2.分布式Session(会话)+网关

• 客户端发起请求，网关实现登录逻辑，登录信息存储到Redis，并且根据Redis的key创建一个Token

• 将Token返回给浏览器，浏览器将Token存储起来
• 浏览器在访问资源的时候请求到网关并携带Token,网关获取到Token，从Redis中获取用户登录信息做检查，没有问题就继续转发Token到后续服务。

• 在后续服务中可以通过Token去Redis中获取认证信息。

2.3.客户端Token+网关

• 客户端发起认证请求，使用JWT等加密方式生成安全的 Token，Token中携带了认证授权信息，然后返回给客户端，

• 客户端存储Token，后续客户端需要访问资源时，携带者Token请求。
• 客户端发起请求，在网关层对Token进行统一检查，检查通过Token继续携带到后端访问中如果涉及到大量的用户信息的存放，可以使用Redis来进行存储。

• 后续服务获取到Token即可获取到用户信息

2.4.其他方案

2.5.我选择的微服务认证授权方案

解释：

• 客户端 : web端，移动端，三方程序
• 认证服务：Oauth2授权服务：负责认证逻辑(登录)和颁发令牌(token)等
• 网关：Oauth2资源服务：负责token统一鉴权

• 资源服务：用户对资源的访问权限检查和返回资源

• 客户端向认证服务发起认证请求，认证服务执行认证流程
• 认证成功，认证服务根据用户认证信息，授权信息颁发Token，Token中包含了认证授权信息
• 客户端存储Token，并向资源服务发起请求，请求头携带Token
• 请求先到达Zuul网关，我们可以在网关层校验Token，当然也可以不在网关层校验Token，而是在每个资源服务器上校验Token
• Token校验通过，资源服务获取到Token中的权限信息对资源进行授权，授权成功返回资源数据，授权失败返回错误

• 如果请求需要多个资源服务共同完成，那么我们还需要考虑在服务调用的使用把Token通过请求头传递给下一个被调用的微服务进行授权