无状态认证 JWT+RSA鉴权

使用场景

当我们将网站部署在多台服务器时 ，使用传统的登录认证（有状态认证），当我们在A服务器 记录登录信息，但访问另一台服务器时，反而需要重新授权，引出了cookie的共享的问题。

---

一， 有状态认证及无状态认证的区别

有状态认证：

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

弊端：

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

集中式（单机版）认证流程：
分布式认证流程（单点登录 CAS:

无状态认证：

服务端不存储用户的登录信息 ， 而是将服务器的压力分担给客户端

• 当客户端第一次请求服务时，服务端对用户进行信息认证（登录）
• 认证通过，将用户信息进行加密形成token，返回给客户端（保存到Cookie中），作为登录凭证
• 客户端以后每次请求，客户端都携带Cookie中的认证信息的token
• 服务端对token进行解密，判断是否有效（身份合法性校验）。
• 服务端从token中解析出登录用户信息（用户ID，用户角色等）
  这是 我们会想到 token 以什么格式，什么内容，以及以什么加密方式，存储到客户端的cookie中？

二、JWT

什么是jwt？

JWT，全称是Json Web Token， 是JSON风格轻量级的授权和身份认证规范，可实现无状态、分布式的Web应用授权；
JWT，生成Token加密字符串的一个标准或格式！

JWT格式的三部分数据：

（1）Header：头部，通常头部有两部分信息：

• 声明类型，这里是JWT
• 签名算法，自定义

我们会对头部进行base64编码，得到第一部分数据：

（2）Payload：载荷，就是有效数据，一般包含下面信息：

• 用户身份信息（注意，这里因为采用base64加密，可解密，因此不要存放敏感信息）
• tokenID：当前这个JWT的唯一标示
• 注册声明：如token的签发时间，过期时间，签发人等

这部分也会采用base64加密，得到第二部分数据

前两部分的数据是用base64编码，这是一种，可以解密的编码，只是起到了混淆的作用，是不具有安全性的

（3）Signature：签名，是整个数据的认证信息。
一般根据前两步的数据，再加上服务的的密钥（secret）（不要泄漏，最好周期性更换），通过加密算法生成。用于验证整个数据完整和可靠性

如图所示：签名中决定整个token是否安全的关键在盐。

最终生成的token格式如图：

三、RSA加密算法

加密算法有多种，这里我们比较其中俩种的算法

（1）JWT+HS256算法：

授权流程：

• 1、用户请求登录，携带用户名密码到授权中心
• 2、授权中心携带用户名密码，到用户中心查询用户
• 3、查询如果正确，生成JWT凭证
• 4、返回JWT给用户

鉴权流程：

• 1、用户请求某微服务功能，携带JWT
• 2、微服务将jwt交给授权中心校验
• 3、授权中心返回校验结果到微服务
• 4、微服务判断校验结果，成功或失败
• 5、失败则直接返回401
• 6、成功则处理业务并返回

上面的流程存在一个问题：

因为JWT校验所需的盐统一存放在授权中心，所以每个微服务每次都需要把JWT交给授权中心进行校验，这样效率就降低了！能不能改善呢？可以的，这时可以使用RSA非对称加密来完善以上流程。

jwt + RSA非对称加密

• 基本原理：同时生成两把密钥：私钥和公钥（ssh），私钥隐秘保存，公钥可以下发给信任客户端
• 私钥加密，持有私钥或公钥才可以解密
• 公钥加密，持有私钥才可解密
• 优点：安全，难以破解
• 缺点：算法比较耗时

登录和鉴权流程：

• 生成RSA密钥对，私钥存放在授权中心，公钥下发给微服务
• 在授权中心利用私钥对JWT签名
• 在微服务利用公钥验证签名有效性

因为非对称加密的特性，不用担心公钥泄漏问题，因为公钥是无法伪造签名的，但要确保私钥的安全和隐秘。

总结：

JWT+RSA 无状态认证： 就是将原本存储在服务端Session域中的登录信息以JWT格式规范（头部，载荷）++上 通过私钥加密后的签名，通过cookie存储在浏览器中，浏览器每次请求时，都会携带token到服务端，通过公钥解密。（可以取出载荷中携带的用户信息）

链接: （代码案例（留给占位符））link.