从零开始SpringCloud Alibaba电商系统(九)——基于Spring Security OAuth2实现SSO(非JWT)

零、系列

欢迎来嫖从零开始SpringCloud Alibaba电商系列:

  1. 从零开始SpringCloud Alibaba电商系统(一)——Alibaba与Nacos服务注册与发现
  2. 从零开始SpringCloud Alibaba电商系统(二)——Nacos配置中心
  3. 从零开始SpringCloud Alibaba电商系统(三)——Sentinel流量防卫兵介绍、流量控制demo
  4. 从零开始SpringCloud Alibaba电商系统(四)——Sentinel的fallback和blockHandler
  5. 从零开始SpringCloud Alibaba电商系统(五)——Feign Demo,Sentinel+Feign实现多节点间熔断/服务降级
  6. 从零开始SpringCloud Alibaba电商系统(六)——Sentinel规则持久化到Nacos配置中心
  7. 从零开始SpringCloud Alibaba电商系统(七)——Spring Security实现登录认证、权限控制
  8. 从零开始SpringCloud Alibaba电商系统(八)——用一个好看的Swagger接口文档

一、概念

基于Cookie和Session的会话机制

介绍OAuth2之前,让我们先来回顾一下早期的登录认证流程。
远古时期,互联网上还只是一个共享的地方,没有谁不能看什么这样的概念;随着时代发展,互联网引用丰富,基于商业和隐私,人们对登录认证有了需求,但是大家都知道HTTP本身是无状态的协议,是没办法让HTTP来识别用户身份的。

于是在上古时期,HTTP引入了Authorization请求头,用户可以将自己的用户名密码放入到这个请求头中,服务端收到一条请求时先解析Authorization请求头,确认用户身份。

中古时期,人们觉得HTTP请求头在自己内网用用还行,放在互联网上太危险了,毕竟用户名密码就在HTTP的请求头里面放着,随便谁拦截了都能看的清清楚楚,都能copy你的信息冒充你来请求资源。

于是大家都开始自己搞认证,而自己搞最常用的方式便是基于Form表单的自定义认证方式,毕竟Form表单中的数据属于自定义请求数据,而Aithorization属于HTTP的标准请求头。Form表单认证,基本上就等同于基于Cookie和Session的会话机制

典型的会话机制如下图所示,服务器端维护一个会session,客户端持有这个session的id,这样只要你登录一次,服务器端就知道你是谁了。大致流程是这样的:
在这里插入图片描述
越过千年的羁绊,再看现在,由于当下分布式、微服务的常规化,大部分企业都已经不再是单体应用服务器,那么Session的使用便成为一个问题。

SSO就是解决这一类问题的方案的统称,俗称单点登录,即对于用户来说,登录系统就是登录了,我不需要在乎你里面有几个子系统,内部复杂度自己搞定。

JWT

众多解决方案之中,有一个亮眼的存在——JWT(JSON Web Token)

JWT不是基于Session工作的,而是将用户信息使用一种加密方式全都存放在cookies中,这样的方式显然能处理分布式系统的登录问题,因为只要持有JWT令牌,你愿意访问哪个子系统就访问哪个子系统,你愿意何时访问就何时访问。

但是问题在于这个随意,令牌就像央行发出去的钞票,太难控制了,服务器系统不知道是谁拿着令牌,务器端不进行保存/管理,即jwt令牌一旦发放,其销毁、续期、登出等功能将很难控制。

话无绝对,人总是聪明的,解决方法总是有的,有兴趣的朋友可以多了解一下jwt,现在它还是很流行的:https://jwt.io/introduction/

OAuth2

我们今天的主角是OAuth2:OAuth2是一种可用于实现SSO单点登录的一种协议。

OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限。同时为Web应用,桌面应用和手机,和起居室设备提供专门的认证流程。 ————— 百度百科

OAuth2协议的官方文档:https://tools.ietf.org/html/rfc6749

综(说)上(句)所(人)述(话),OAuth2的核心就是:服务器就负责提供服务,用户端就负责消费服务,认证和授权的事情都交给认证服务器,资源服务器就只提供资源,简要思想见下图。

这个OAuth2怎么好用了呢?让我们来用Session作详细描述(首先让我们承认直接使用Session比使用JWT这样方法出去的令牌好简单方便,对用户更友好)。

  1. 用户需要访问工单系统,需要登录,于是发送用户密码到工单系统。
  2. 工单系统不直接鉴权,而是将用户请求、自己的回调地址都转发给认证中心。
  3. 认证中心知道用户要登录,于是给用户一个登录页面,让用户输用户密码。
  4. 认证中心拿到用户密码进行鉴权,认证通过,ok,我认证中心建立一个全局Session,代表这个用户在我这个系统已经登陆了,然后,由于此时认证中心还持有工单系统的回调地址,所有可以直接发送给工单系统一个授权码
  5. 工单系统拿到授权码,再次通过授权码向工单系统请求授权令牌
  6. 认证中心校验授权码,ok没问题,给你工单系统一个令牌。
  7. 工单系统拿到令牌,就有权限访问资源服务器上的相关资源了。同时工单系统与用户建立了局部Session,两者可以顺畅交互。

在这里插入图片描述
大家会发现,感觉好像和JWT这种直接将令牌发给用户的方式有些类似,确实类似,类似在令牌由认证中心授权给工单系统(俗称client系统),而非直接给用户。 client系统拥有资源访问权限,且与用户建立局部Session后,就可以实现一个用户端的无Token访问,即用户不需要再持有Token令牌了,对于我用户来说,还和单机时代一样,持有个局部Session id就行。

工单系统解决了认证问题,那运维系统呢?按理来说对于我用户来说已经登录了,点开运维系统应该不用登陆了,这才符合SSO单点登录原则嘛!

对于新的要访问的子系统,OAuth2是这样做的:

  1. 用户对运维系统发起请求。
  2. 运维系统同样将请求、自身回调地址转发给认证中心。
  3. 认证中心发现该用户的全局Session存在,不再鉴权,直接给运维系统一个授权码
  4. 运维系统拿到授权码,向认证中心请求授权令牌
  5. 认证中心校验授权码,校验没问题,返回授权令牌
  6. 运维系统拿到授权令牌,可以访问资源服务器了,同时与用户建立局部Session

细心的同学可能发现了,运维系统与工单系统不同的地方仅仅在于,运维系统的鉴权直接由认证中心完成,没有再让用户来一次登录操作。除此之外,其他操作都一模一样。

二、OAuth2认证服务器搭建

TODO 待续,很快补上。。。

发布了88 篇原创文章 · 获赞 28 · 访问量 3万+

猜你喜欢

转载自blog.csdn.net/qq_35946969/article/details/105695243