微服务认证授权：常见的授权方案

最新推荐文章于 2024-09-24 19:57:24 发布

财经界巨子-吵死你

最新推荐文章于 2024-09-24 19:57:24 发布

阅读量2.9k

点赞数 2

分类专栏： SpringCloud 文章标签： spring java

原文链接：https://blog.csdn.net/u014494148/article/details/108651304?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522161468797316780262528767%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=161468797316780262528767&biz_i

版权

SpringCloud 专栏收录该内容

2 篇文章 1 订阅

订阅专栏

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的访问流程：
在这里插入图片描述

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

系统B的访问流程：
在这里插入图片描述

浏览器(同一个浏览器)访问另外一个客户端系统B，系统B检查到没有登录，请求重定向到认证中心
由于浏览器在访问系统A的时候已经到了登录，cookie中有TGC,所以认证中心可以获取到TGC找到对应的TGT
认证中心根据cookie中的TGC找到TGT，代表用户登录过，于是创建ticket,并重定向请求到系统B，带着参数ticket
系统B接收到请求，拿着ticket去认证中心校验Ticket
认证中心ticket校验通过，返回用户信息

这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显，而且这种方案不太适合移动端认证方案。

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

这种方案是在网关做登录，以及登录检查，登录会话通过Redis进行分布式会话存储，后端微服务可以从共享会话Redis中获取认证信息，当然这里我们可以使用Redis的 key 来生成一个Token然后相应给客户端，客户端存储Token。当访问资源的时候携带者Token去后台，在网关层根据Token检查分布式会话是否完成登录。
在这里插入图片描述