JWT与RSA策略实现服务无状态与请求鉴权思路

╰+攻爆jí腚メ 2022-10-23 11:10 168阅读 0赞

# JWT与RSA策略实现服务无状态与请求鉴权思路 #

## 有状态与无状态 ##

**有状态：**

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如tomcat中的session。

例如登录：用户登录后，我们把登录者的信息保存在服务端session中，并且给用户一个cookie值，记录对应的session。然后下次请求，用户携带cookie值来，我们就能识别到对应session，从而找到用户的信息。

缺点是什么？

*  服务端保存大量数据，增加服务端压力
 *  服务端保存用户状态，无法进行水平扩展
 *  客户端请求依赖服务端，多次请求必须访问同一台服务器，不利于分布式项目

**无状态：**

微服务集群中的每个服务，对外提供的都是Rest风格的接口。而Rest风格的一个最重要的规范就是：服务的无状态性，即：

*  **服务端不保存任何客户端请求者信息**
 *  客户端的每次请求必须具备**自描述信息**，通过这些信息识别客户端身份

好处是什么？

*  客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务
 *  服务端的集群和状态对客户端透明
 *  服务端可以任意的迁移和伸缩
 *  减小服务端存储压力

## 无状态实现 ##

无状态登录的流程：

*  当客户端**第一次**请求服务时，服务端对用户进行信息认证（登录）
 *  认证通过，将用户信息进行加密形成**token**，返回给客户端，作为登录凭证
 *  以后每次请求，客户端都携带认证的token
 *  服务的**对token进行解密**，判断是否有效。

流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70][]

整个登录过程中，最关键的点是什么？

**token的安全性**

token是识别客户端身份的唯一标示，如果加密不够严密，被人伪造那就完蛋了。

采用何种方式加密才是安全可靠的呢？

我们将采用`JWT + RSA非对称加密`

## JWT ##

JWT，全称是Json Web Token， 是JSON风格轻量级的授权和身份认证规范，可实现无状态、分布式的Web应用授权；官网：https://jwt.io

JWT包含三部分数据：

*  Header：头部，通常头部有两部分信息：
    
     *  声明是JWT类型
    
    我们会对头部进行base64编码，得到第一部分数据
 *  Payload：载荷，就是有效数据，一般包含下面信息：
    
     *  用户身份信息（注意，这里因为采用base64编码，可解码，因此不要存放敏感信息）
     *  注册声明：如token的签发时间，过期时间，签发人等
    
    这部分也会采用base64编码，得到第二部分数据
 *  Signature：签名，是整个数据的认证信息。一般根据前两步的数据，**再加上服务的的密钥（secret）**（不要泄漏，最好周期性更换），通过加密算法生成。用于验证整个数据完整和可靠性

生成的数据格式：token==个人证件 jwt=个人身份证

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 1][]

可以看到分为3段，每段就是上面的一部分数据

流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 2][]

步骤翻译：

*  1、用户登录，向服务端传输用户名和密码
 *  2、服务的认证，通过后根据密钥secret生成token（JWT类型）
 *  3、将生成的token返回给浏览器
 *  4、用户每次请求携带token
 *  5、服务端利用**公钥**解读jwt签名，判断签名有效后，从Payload（载荷）中获取用户信息
 *  6、处理请求，返回响应结果

因为JWT签发的token中已经包含了用户的身份信息，并且每次请求都会携带，这样服务的就无需保存用户信息，甚至无需去数据库查询，完全符合了Rest的无状态规范。

## 微服务下结合Zuul的鉴权流程 ##

没有RSA加密时，我们可以把服务的鉴权操作放到网关中，将未通过鉴权的请求直接拦截，如图：

将未通过鉴权的请求直接拦截，如图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 3][]

*  1、用户请求登录
 *  2、Zuul将请求转发到授权中心，请求授权
 *  3、授权中心校验完成，颁发JWT凭证
 *  4、客户端请求其它功能，携带JWT
 *  5、Zuul将jwt交给授权中心校验，通过后放行
 *  6、用户请求到达微服务
 *  7、微服务将jwt交给鉴权中心，鉴权同时解析用户信息
 *  8、鉴权中心返回用户数据给微服务
 *  9、微服务处理请求，返回响应

发现什么问题了？

每次鉴权都需要访问鉴权中心，系统间的网络请求频率过高，效率略差，鉴权中心的压力较大。

## 结合RSA的鉴权 ##

直接看图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 4][]

*  我们首先利用RSA非对称加密生成公钥和私钥。私钥保存在授权中心，公钥保存在Zuul和各个信任的微服务
 *  用户请求登录
 *  授权中心校验，通过后用**私钥对JWT进行签名加密**
 *  返回jwt给用户
 *  用户携带JWT访问
 *  **Zuul直接通过公钥解密JWT，进行验证，验证通过则放行**
 *  **请求到达微服务，微服务直接用公钥解析JWT，获取用户信息，无需访问授权中心**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70]: /images/20221023/e5ab8bac06cd41888f8189526cc733be.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 1]: /images/20221023/dd16d3f6467648a1b89d955270178355.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 2]: /images/20221023/6b5bd95a6be74851b96f2af43152f404.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 3]: /images/20221023/0338873855b3446abfabcb40e121e29d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0p1blNJcmhs_size_16_color_FFFFFF_t_70 4]: /images/20221023/78fc30418dd74ec7b07a85b1cc151e24.png