微服务架构-服务网关(Gateway)-权限认证(分布式session替代方案)

权限认证-分布式session替代方案

前面我们了解了Gateway组件的过滤器,这一节我们就探讨一下Gateway在分布式环境中的一个具体用例-用户鉴权。

1、传统单应用的用户鉴权

从我们开始学JavaEE的时候,就被洗脑式灌输了一种权限验证的标准做法,那就是将用户的登录状态保存到HttpSession中,比如在登录成功后保存一对key-value值到session,key是userld而value是用户后台的真实ID。

接着创建一个ServletFilter 过滤器,用来拦截需要登录才能访问的资源,假如这个请求对应的服务端session里找不到userld这个key,那么就代表用户尚未登录,这时候可以直接拒绝服务然后重定向到用户登录页面。

大家应该都对session机制比较熟悉,它和cookie是相互依赖的,cookie是存放在用户浏览器中的信息,而session则是存成在股务器端的。当浏览器发起服务请求的时候就会带上cookie,服务器端接到Request后根据cookie中的jsessionid拿到对应的session。

由于我们只启动一台服务器,所以在登录后保存的session始终都在这台服务器中,可以很方便的获取到 session中的所有信息,用这方法我们一路搞定了各种课程作业和毕业设计,结果一到工作岗位发现行不通了,因为所有应用都是集群部署,在一台机器保存了的session无法同步到其他机器上,那我们有什么成熟的解决方案吗?

2、分布式环境下的解决方案

2.1)同步session

session复制是最容易先想到的解决方案,我们可以把一台机器中的session复制到集群中的其他机器。

比如Tomcat中也有内置的session同步方案,但这并不是一个很优雅的解决方案,它会带来以下两个问题:

Timing问题: 同步需要花费一定的时间,我们无法保证session同步的及时性,也就是说,当用户发起的两个请求分别落在不同机器上的时候,前一个请求写入session的信息可能还没同步到所有机器,后一个请求就已经开始执行业务逻辑了,这不免引起脏造幻读。

数据冗余: 所有服务器都需要保存一份session全集,这就产生了大量的冗余数据

2.2)反向代理: 绑定IP或一致性Hash

这个方案可以放在Nginx网关层做,我们可以指定某些IP段的请求落在某指定机器上,这样一来session始终只存在一台机器上,不过相比前一种session复制的方法来说,绑定IP的方式有更明显的缺陷:

负载均衡: 在绑定IP的情况下无法在网关层应用负载均衡策略,而且某个服务器出现故障的话会对指定IP段的来访用户产生较大影响,对网关层来说该方案的路由规则配置也极其麻烦;

IP变更: 很多网络运营商会时不时切换用户IP,这就会导致更换IP后的请求被路由到不同的服务节点处理,这样一来就读不到前面设置的session信息了。

为了解决第二个问题,可以通过一致性Hash的路由方案来做路由,比如根据户ID做Hash,不的Hash值落在不同的机器上,保证足够均匀的分配,这样也就避免了IP切换的问题,但依然无法解决第一点里提到的负载均衡问题。

2.3)Redis解决方案

这个方案解决了前面提到的大部分问题,session不再保存在服务器上,取而代之的是保存在redis中,所有的服务器都向redis写入/读取缓存信息。

在Tomcat层面,我们可以直接到入tomcat-redis-session-manager组件,将容器层面的session组件替换为基于redis的组性,但是这种方案和容器绑定的比较紧密。

另一个更优雅的方家是借助spring-session管理redis中的session。尽管这个方案脱离了具体容器,但依然是基于session的用户鉴权方案,这类session方案已务在微服务应用被淘汰了。

2.4)分布式Session的替代方案

让我们把session抛到脑后,看看现在流行的两种认证方式:

2.4.1)OAuth 2.0

大家一定用过现在比较流行的第三方登录,比如我们通过微信扫码登录就可以登录某个应用的在线系统,但是这个应用并不知道我的微信用户名和密码,这便是我们要介绍的第一个鉴权方案-OAuth 2.0。

OAuth 2.0是一个开放授权标准协议,它允许用户让第三方应用访问该用户在某服务的特定私有资源,但是不提供账号密码信息给第三方应用。

在上面的例子中,微信就相当于一个第三方应用,我们通过OAuth 2.0拿微信登录第三方应用的例子来说:
在这里插入图片描述

  • Auth Grant : 在这一步CIient发起 Authorization Request 到微信系统(比如通过微信内扫码授权),当身份验证成功后获取Auth Grant;
  • Get Token: 客户端拿着从微信获取到的Auth Grant,发给第三方引用的鉴权服务,换取一个Token,这个Token就是访问第三方应用资源所需要的令牌;
  • 访问资源: 最后一步,客户端在请求资源的时候带上Token令牌,服务端验证令牌真实有效后即返回指定资源。

我们可以借助Spring Cloud中内置的 spring-cloud-starter-oauth2 组件搭建OAuth 2.0的鉴权服务,OAuth 2.0的协议还涉及到很多复杂的规范,比如角色、客户端类型、授权模式等。这一小节我们暂且不深入探讨OAuth 2.0的实现方式,先来看另外一个更轻量级的授权方案:JWT鉴权。

2.4.2)JWT鉴权

JWT也是一种基于Token的鉴权机制,它的基本思想就是通过用户名+密码换取一个Access Token。

2.4.2.1)鉴权流程

相比OAuth 2.0来说,它的鉴权过程更加简单,其基本流程是这样的:

1、用户名+密码访问鉴权服务

  • 验证通过:服务器返回一个Access Token给客户端,并将token保存在服务端某个地方用于后面的访问控制(可以保存在数据库或者Redis中);
  • 验证失败:不生成Token。

2、客户端使用令牌访问资源,服务器验证令牌有效性

  • 令牌错误或过期:拦截请求,让客户端重新申请令牌;
  • 令牌正确: 允许放行
2.4.2.2)Access Token中的内容

JWT的Access Token由三个部分构成,分别是Header、 Payload和Signature,我们分别看下这三个部分都包含了哪些信息:

Header: 头部声明了Token的类型 (JWT类型) 和采用的加密算法 (HS256);

{
  'typ': 'JWT',
  'alg': 'HS256'
}

**Payload:**这一段包含的信息相当丰富,你可以定义Token签发者、签发和过期时间、生效时间等一系列属性,还可以添加自定义属性,服务端收到Token的时候也同样可以对Payload中包合的信息做验证,比如说某个Token的签发者是"Feign-API",假如某个接口只能允许"Gateway-API"签发的Token,那么在做鉴权服务时就可以加入lssuer的判断逻辑。

Signature: 它会使用Header和Payload以及一个密钥用来生成签证信息,这一步会使用Header里我们指定的加密算法进行加密

目前实现JWT的开源组件非常多,如果决定使用这个方案,只要添加任意一个开源JMT实现的依赖项到项目中的POM文件,然后在加解密时调用该组件来完成。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>