微服务认证授权：常见的授权⽅案
微服务认证授权：常见的授权⽅案
1.前⾔
前⾯我们讨论的是SpringSecurity基础部分内容，接下来我们来探讨⼀下SpringCloud 集成 SpringSecurity和Oauth实现微服务认证授权⽅案
2.微服务(分布式)项⽬常见认证⽅案
2.1.微服务授权⾯临哪些问题
在微服务架构下有很多的服务，每个微应⽤都需要对访问进⾏认证检查和权限控制，客户端发起⼀个请求需要考虑如何让⽤户的认证状态通知到所有的微服务中，尤其是请求来源于多种客户端如浏览器，移动端，三⽅程序，服务之间访问时，微服务的授权变得更加⿇烦，再加上本地Session在微服务(集/分布式)环境中存在Session不同步的问题，所以我们微服务授权是⾮常⾮常复杂的。
Session不同步问题如图：
2.2.微服务常见认证⽅案
2.2.1.CAS单点登录
CAS是⼀种基于Cookie实现的单点登录⽅案，页是⼀个⽐较⽼的解决⽅案，是 Yale ⼤学发起的⼀个开源项⽬，旨在为 Web 应⽤系统提供⼀种可靠的单点登录⽅法，它分为 CAS Server端和CAS Client端，Server端负责⽤户的登录流程，Client端需要整合到各个系统中，它的登录流程如下：
系统A的访问流程：
1. 浏览器请求系统A，系统A检查到没有登录，重定向到认证服务，并且携带参数service，这个参数的作⽤是在认证中⼼认证通过之后
会再跳回系统A的重定向地址
2. 请求跳转到认证中⼼，认证中⼼接收到请求，返回登录页⾯，⽤户提交登录信息
3. 认证中⼼执⾏登录逻辑，认证成功，⽣成ticket（ST）和 TGC，认证中⼼会将TGC写到浏览器的cookie，有这个东西说明⽤户登录
过，通过TGC可以到TGT
4. 然后认证中⼼将请求再重定向到系统A(根据之间的service参数回调地址)，并且携带⼀个ticket参数
5. 请求跳转回了系统A，系统A得到ticket，向认证中⼼发起请求校验ticket的合法性
6. 认证中⼼验证ticket通过，向client返回对应的⽤户信息
系统B的访问流程：
1. 浏览器(同⼀个浏览器)访问另外⼀个客户端系统B，系统B检查到没有登录，请求重定向到认证中⼼
2. 由于浏览器在访问系统A的时候已经到了登录，cookie中有TGC，所以认证中⼼可以获取到TGC到对应的TGT
3. 认证中⼼根据cookie中的TGC到TGT，代表⽤户登录过，于是创建ticket，并重定向请求到系统B，带着参数ticket
4. 系统B接收到请求，拿着ticket去认证中⼼校验Ticket
5. 认证中⼼ticket校验通过，返回⽤户信息
这种⽅案意味着每个⾯向⽤户的服务都必须与认证服务交互，这会产⽣⼤量⾮常琐碎的⽹络流量和重复的⼯作，当动辄数⼗个微应⽤时，这种⽅案的弊端会更加明显，⽽且这种⽅案不太适合移动端认证⽅案。
2.2.2.分布式Session(会话)+⽹关
这种⽅案是在⽹关做登录，以及登录检查，登录会话通过Redis进⾏分布式会话存储，后端微服务可以从共享会话Redis中获取认证信息，当然这⾥我们可以使⽤Redis的 key 来⽣成⼀个Token然后相应给客户端，客户端存储Token。当访问资源的时候携带者Token去后台，在⽹关层根据Token检查分布式会话是否完成登录。
1. 客户端发起请求，⽹关实现登录逻辑，登录信息存储到Redis，并且根据Redis的key创建⼀个Token
将Token返回给浏览器，浏览器将Token存储起来
2. 浏览器在访问资源的时候请求到⽹关并携带Token,⽹关获取到Token，从Redis中获取⽤户登录信息做检查，没有问题就继续转发
Token到后续服务。
3. 在后续服务中可以通过Token去Redis中获取认证信息。
这种⽅案需要注意对共享会有⼀定的保护机制，并且实现也有⼀定的实现难度
2.2.
3.客户端Token+⽹关
客户端Token是⼀种⽐较常⽤的认证⽅案，有点在于Token中携带了⽤户信息在服务之间传输，做到了⽆状态，可以通过JWT等安全机制加密Token保证Token的安全性
1. 客户端发起认证请求，使⽤JWT等加密⽅式⽣成安全的 Token，Token中携带了认证授权信息，然后返回给客户端，
2. 客户端存储Token，后续客户端需要访问资源时，携带者Token请求。
3. 客户端发起请求，在⽹关层对Token进⾏统⼀检查，检查通过Token继续携带到后端访问中如果涉及到⼤量的⽤户信息的存放，可以
使⽤Redis来进⾏存储。
4. 后续服务获取到Token即可获取到⽤户信息
客户端Token⽅案的好处在于可以做到⽆状态，因为Token中包含了⽤户信息，服务端不⽤考虑存储⽤户信息，缺点在于Token过长造成的⽹络传输的开销。
2.2.4.其他⽅案
当然解决单点登录还有其他⽅案，⽐如使⽤SpirngSession+Redis实现Session共享，或是配置服务器之间的Session同步，亦或是使⽤Nginx的负载均衡策略url hash⼀致性来解决，总归来说解决⽅案五花⼋门，选择适合项⽬的⽅案是最重要的
2.3.如何选择
CAS单点登录⽅案是⽐较早期的⽅案，且会产⽣⼤量⽹络请求，消耗资源；【不推荐】
分布式Session（Redis）：适⽤于中⼩型项⽬，采⽤Redis来代替Session，我们项⽬⼆就是采⽤的这个⽅案；
客户端Token：适⽤于⼤型项⽬（微服务架构项⽬）；
2.3.1.SpringCloud+SpringSecurity+OAuth2+JWT
2.3.2.SpringCloud+SpringSecurity+OAuth2+JWT+Zuul
解释：
客户端 : web端，移动端，三⽅程序
认证服务：Oauth2授权服务：负责认证逻辑(登录)和颁发令牌(token)等
⽹关：Oauth2资源服务：负责token统⼀鉴权
资源服务：⽤户对资源的访问权限检查和返回资源
它的⼤概流程是：
客户端向认证服务发起认证请求，认证服务执⾏认证流程
认证成功，认证服务根据⽤户认证信息，授权信息颁发Token，Token中包含了认证授权信息
客户端存储Token，并向资源服务发起请求，请求头携带Token
请求先到达Zuul⽹关，我们可以在⽹关层校验Token，当然也可以不在⽹关层校验Token，⽽是在每个资
常用微服务架构源服务器上校验Token Token校验通过，资源服务获取到Token中的权限信息对资源进⾏授权，授权成功返回资源数据，授权失败返回错误
如果请求需要多个资源服务共同完成，那么我们还需要考虑在服务调⽤的使⽤把Token通过请求头传递给下⼀个被调⽤的微服务进⾏授权

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。