浅析JWT原理及牛客出现过的相关面试题

原文链接：https://kixuan.github.io/posts/f568/
对jwt总是一知半解，而且项目打算写个关于JWT登录的点，所以总结关于JWT的知识及网上面试考察过的点

参考资料：

Cookie、Session、Token、JWT_通俗地讲就是验证当前用户的身份,证明-CSDN博客

JSON Web Token 入门教程 - 阮一峰的网络日志

https://cloud.tencent.com/developer/article/2231547

JWT详细讲解(保姆级教程)-阿里云开发者社区

JWT双令牌(双token)实现登录验证_双token三验证-CSDN博客

零、前置知识

cookie、session、token的区别

cookie：用于在客户端存储会话信息，并在之后每个请求中都会通过HTTP头部再将cookie发给服务器 ==》对于敏感信息不安全（跨站脚本、跨站请求伪造）

session：是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中，然后请求服务器的时候只发送Sessionid==》用户量特别大时，服务器容易分配。

token：可以存储在客户端或者服务器端，具体取决于实现方式。常见的做法是将 Token 存储在客户端，比如在 localStorage、sessionStorage 或者浏览器的内存中。///无状态///可拓展性强，可以包含任何信息

Cookie 和 Session 的区别

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

为什么session比cookie安全？

可被篡改性：Cookie 存储在客户端，可以在客户端被修改。相比之下，Session 数据通常存储在服务器端，攻击者无法直接修改。

可被窃取性：同上

持久性：这意味着即使用户关闭浏览器，这些 Cookie 也会被保存在用户的设备上。长时间的持久性可能增加了攻击者窃取 Cookie 的机会

Token 和 Session 的区别

• Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。
• 而 Token 是访问资源接口（API）时所需要的资源凭证，使服务端无状态化，不会存储会话信息。

一、出现背景

在传统的 Web 开发中，为了保持用户的会话状态，通常会使用基于 cookie 和 session 的方式保存相关数据，如用户角色、登陆时间。但也有一些问题，比如跨域资源共享（CORS）和无状态（Stateless）服务。

如果是服务器集群或者需要CORS的架构，要求session数据库共享

解决办法：

1. session数据持久化——写到数据库或者别的持久层，工程量较大；稳定性不高，持久层挂了就会单点失败
2. 服务器不保存session数据，数据保存在客户端，每次请求带上发回给服务器

JSON Web Token（缩写 JWT）是2方案的一个代表，是目前最流行的跨域认证解决方案

基于session的认证流程	基于JWT的认证流程
用户在浏览器中输入用户名和密码，服务器通过密码校验后生成一个session并保存到数据库服务器为用户生成一个sessionId，并将具有sesssionId的cookie放置在用户浏览器中，同时 Cookie 记录此 SessionID 属于哪个域名，在后续的该域名的请求中都将带有这个cookie信息进行访问服务器获取cookie，通过获取cookie中的sessionId查找数据库判断当前请求是否有效	用户在浏览器中输入用户名和密码，服务器通过密码校验后生成一个token并保存到数据库前端获取到token，存储到cookie或者local storage中，在后续的请求中都将带有这个token信息进行访问服务器获取token值，通过查找数据库判断当前token是否有效

二、原理

组成部分

JWT 的原理基于三部分组成：Header、Payload 和 Signature。它们通过点（.）连接在一起，形成一个紧凑的字符串，可以通过 URL、POST 参数或 HTTP 头部发送。

1. Header：包含了两部分信息：令牌的类型（即JWT），以及所使用的签名算法（例如HMAC SHA256或RSA）。
2. Payload：存放着声明（claims），即关于实体（通常是用户）和其他数据的信息。Payload包含了一些预定义的标准声明（如issuer、subject、audience等），同时也可以包含自定义的声明。
3. Signature：用于验证消息的完整性的签名部分。它由将编码的 header、payload 和一个秘密（例如，使用 HMAC 算法时的密钥）进行签名生成。

运行流程

1. Header部分是一个 JSON 对象，描述 JWT 的元数据,使用 Base64URL 算法转成字符串

{"alg": "HS256",  // 签名算法"typ": "JWT"     // 令牌类型
}

1. Payload:服务器认证以后，生成一个 JSON 对象用来存放实际需要传递的数据，再使用 Base64URL 算法转成字符串

// JWT 规定了7个官方字段供选用，也可以定义私有字段
- iss (issuer)：签发人
- exp (expiration time)：过期时间
- sub (subject)：主题
- aud (audience)：受众
- nbf (Not Before)：生效时间
- iat (Issued At)：签发时间
- jti (JWT ID)：编号{"姓名": "张三","角色": "管理员","到期时间": "2018年7月1日0点0分"
}

1. Signature:通过将 Base64 编码后的 Header 和 Payload 与一个秘密（例如，使用 HMAC 算法时的密钥）进行签名生成的。 指定一个密钥，密钥只有服务器知道，然后使用 Header 里面指定的签名算法alg算出签名
2. 客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。此后，客户端每次与服务器通信，都要带上这个 JWT(也可以放在HTTP请求头信息里的Authorization字段,方便跨域)

三、代码实现

参考：JWT双令牌(双token)实现登录验证_双token三验证-CSDN博客

双令牌：无感登录刷新

1. access_token 泄露概率比较大

2. refresh_token 泄露概率比较小,只有每次access_token 失效时才会使用它,所以二者组合可以很好的避免token泄露带来的安全风险,同时又能保证用户体验

3. userService的login方法

   1. 保存refresh token到数据库
   2. access token返回给前端

4. 刷新accessToken：当短时间的token过期，前端需要通过长时间的token来访问后端，并且生成一个短时间的token返回给前端，也就是刷新短时间的token。

5. 删除refreshToken：当用户退出的时候我们需要删除数据库中的refreshToken。

四、相关面试题（来源牛客）

1. jwt的token怎么生成的?/jwt的参数是什么样的，有什么意义

由三个部分组成：Header、Payload 和 Signature。其中，Header 和 Payload 部分是基于 Base64 编码的 JSON 对象，而 Signature 是通过对 Header 和 Payload 进行签名生成的。

+再说运行流程

2. jwt 是明文的吗？

Header 和 Payload 是基于 BaseURL64 编码的 JSON 对象，明文存放的

Signature 是加密的，但是它主要适用于验证JWT的真实性防止被篡改，不存放信息

所以整体来说，JWT还是明文的

3. JWT用到了什么摘要算法

摘要算法：摘要算法又称哈希算法、散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串（通常用16进制的字符串表示）。

要注意摘要算法不是加密算法，不能用于加密（因为无法通过摘要反推明文），只能用于防篡改。

SHA256是一种哈希算法，用于将任意长度的输入数据转换成固定长度的输出（256 位，即 32 字节）

工作原理：

1. 填充数据：首先SHA256 将输入数据填充至满足特定要求的长度，通常在数据末尾添加比特位，以确保数据长度满足要求。
2. 分块处理：将填充后的数据按照固定长度分割成多个块，每个块的长度为 512 比特。
3. 初始哈希值：设定初始的 256 比特哈希值，作为计算的起始点。
4. 迭代运算：对每个块进行迭代运算，结合前一个块的哈希值，计算得到新的哈希值，直到处理完所有块。
5. 输出结果：将最后一个块计算得到的哈希值作为最终的 SHA256 哈希值输出。

特点：

• 固定长度输出：SHA256 输出固定长度的哈希值，即使输入数据的长度不同，输出的哈希值长度仍然相同。
• 不可逆性：SHA256 是一种单向哈希函数，即无法通过哈希值反推出原始数据，保证了数据的安全性。
• 抗碰撞性：SHA256 具有较高的抗碰撞性，即使对不同的输入数据计算得到相同的哈希值的可能性极低，保证了数据的唯一性和完整性。

4. 可以使用md5摘要算法吗？

MD5 摘要算法不建议用于 JWT 的签名，因为 MD5 已经被证明不安全，容易受到碰撞攻击。碰撞攻击是指攻击者能够生成两个不同的输入，但产生相同的哈希值。

为什么选sha256不选md5

1. 摘要长度：SHA256 生成的摘要长度（256 比特）比 MD5 长度（128 比特）更长，因此具有更大的输出空间，更难以发生碰撞（即两个不同的消息产生相同的摘要）。
2. 算法结构：SHA256 是基于 Merkle–Damgard 结构的散列函数，而 MD5 是基于 MD4 结构的。SHA256 的算法结构更为复杂，使用了更多的轮次和更复杂的运算，提高了其抵抗碰撞攻击的能力。
3. 算法安全性：MD5 算法在安全性上存在一些漏洞，如碰撞攻击、预图片攻击等，已经被证明不再安全。而 SHA256 目前尚未出现有效的攻击方法，因此被认为更安全。

5. 了解RAS算法吗？

rsa是一种非对称加密算法，数据可以使用公钥进行加密，然后只有持有相应私钥的一方才能解密该数据。反之，数据也可以使用私钥进行签名，然后任何持有相应公钥的一方都可以验证该签名。

在JWT的应用：私钥用于生成签名，而公钥用于验证签名。这样即使公钥泄露，攻击者也无法伪造有效的签名，从而确保了 JWT 的安全性。

我趣那不是又能深入可以到对称加密和非对称加密

对称加密：相同密钥、快速高效

非对称加密：不同密钥、安全性较高

6. base64算法？base64的流程是什么？

Base64 编码算法：Base64 算法将二进制数据编码成文本字符串，但并不对数据进行加密或者隐藏。它的主要目的是将二进制数据转换成纯文本格式，以便于传输或者存储。【24位转32位】

1. 把数据按照24位（3 字节）为一组进行划分
2. 转成ASCII编码——转成二进制编码（24位）——每6位一组转成十进制（4个数字）——转成对应的ASCII编码——转成二进制（32位）
3. 如果输入数据的长度不是 3 的整数倍，则需要添加一定数量的填充字符 “=”，使得每个 24 位的组都能够被正确地转换成四个 Base64 字符。

参考：https://blog.csdn.net/qq_19782019/article/details/88117150

7. 双令牌认证方案是怎么实现的

同时使用访问令牌（Access Token）和刷新令牌（Refresh Token）来实现用户认证和无感登录刷新。这种方案可以有效地提高安全性和用户体验，具体实现方式如下：

1. 认证过程：
   1. 用户使用用户名和密码等凭据进行登录，服务器验证用户身份并生成 Access Token 和 Refresh Token。
   2. Access Token 用于访问受保护的资源，通常具有较短的有效期，比如几分钟到几小时。
   3. Refresh Token 用于获取新的 Access Token，通常具有较长的有效期，比如几天到几个月。
2. Access Token 过期处理：当 Access Token 过期时，用户需要使用 Refresh Token 来获取新的 Access Token，而无需重新输入用户名和密码。
3. Refresh Token 安全性：
   1. Refresh Token 通常具有较长的有效期，因此需要确保其安全性，防止被盗用。可以通过以下方式提高其安全性：
      • 将 Refresh Token 存储在安全的地方，比如 HTTP-only Cookie 或者安全存储。
      • 使用 HTTPS 加密传输 Refresh Token，防止被中间人窃取。
4. Access Token 的定期刷新：在获取新的 Access Token 时，可以同时返回新的 Refresh Token，以确保用户持续的访问权限。

通过双令牌认证方案，用户可以在不影响用户体验的情况下持续访问受保护的资源，并且可以有效地提高安全性，防止令牌被截取或滥用。

8 .为什么需要JWT？/解决了什么问题？相比之前的 cookie + session ，改用 jwt 有什么好处？

JWT 和cookie + session功能类似，都是用于身份验证和授权

优点：

1. 无状态：服务器不需要再内存中保存用户的会话信息，因为JWT中已经包含了用户的所有必要信息
2. 跨域支持：因为JWT是在网络请求的头部中传输的，而cookie+session跨域访问需要额外的配置和处理
3. 可扩展性强：可以包含任意的Json数据，满足不同场景的需求
4. 性能更好：减少服务器负载，还可以通过缓存或者CDN进行缓存，进一步提升性能
5. 安全性：数字签名和加密算法

9. 整个JWT是怎么设计的

1. 令牌类型：JWT（JSON Web Token）
2. 令牌内容：确定令牌中包含的信息，如用户身份信息、权限信息、过期时间等。
3. 令牌签名或加密：使用后SHA256进行签名
4. 令牌传输： HTTPS 加密通信
5. 令牌存储：本地存储（如 Local Storage 或者 Session Storage）、HTTP Only Cookie 中
6. 令牌刷新机制：双令牌认证方案
7. 令牌管理：好像没有

Or 见代码实现part

10. 令牌存储/为什么用redis存jwt

本地：Local Storage

服务器：Redis

提高性能、减轻数据库负担、高可用性、分布式系统、数据持久化

11. 怎么防止别人用你的token干坏事

分两步：防止别人拿到token；防止别人干坏事

防止别人拿到token：

1. 使用安全的传输协议：比如使用 HTTPS 协议来加密通信，防止中间人窃取 token。
2. 限制 token 的使用有效期，刷新 token 机制
3. 使用签名验证：在验证 token 时，确保 token 的签名是有效的，并且是由信任的签发者签发的。这可以防止伪造 token 或者篡改 token 内容。

防止别人干坏事：

1. 限制 token 的使用范围：限制 token 只能用于特定的 API 路径或者特定的操作
2. 定期监控 token 的使用情况

12. 使用JWT时，如果一个用户把token给了另外一个用户恶意同时登录怎么处理 ?

1. 限制令牌的使用范围：可以在 JWT 中包含一些额外的声明（Claims），如用户的 IP 地址、用户角色等信息
2. 实施单点登录（SSO）限制用户同时登录的设备数量
3. 限制有效期
4. 定期监控

13. 对比jwt与token

• 格式：JWT 是一种特定的令牌格式，它使用 JSON 对象作为载荷，并使用签名或加密来保证其完整性和安全性。而 Token 则是一个更广义的概念，可以是任何形式的凭证。
• 安全性：JWT 通过签名或加密来保证其安全性，而普通的 Token 可能没有这种安全保障。
• 使用场景：JWT 主要用于实现无状态的身份验证和授权，而 Token 可以用于各种场景，包括 OAuth 授权、访问令牌、刷新令牌等。

总的来说，JWT 是 Token 的一种特定格式，它具有一定的安全性和标准化，适用于实现无状态的身份验证和授权。而 Token 则是一个更广义的概念，可以是各种形式的凭证，用于各种身份验证和授权场景。

14. cookie了解吗

存储在客户端的小型文本文件，用于跟踪用户在网站上的活动，并且在用户访问同一网站时发送回服务器。

它们经常被用来实现用户认证、会话跟踪、个性化设置等功能。

由一组名称/值对组成，以及一些可选的属性。

属性：name——表示名称

expires——过期时间

path——可以访问路径

domain——可访问域名

secure—— 只能通过 HTTPS 连接传输

HttpOnly——只能通过 HTTP 或 HTTPS 协议访问，而不能通过客户端脚本（如 JavaScript）访问，以防止跨站脚本（XSS）攻击。

使用cookie需要注意安全性：跨站脚本（XSS）攻击和跨站请求伪造（CSRF）

15. 再让你优化项目还能怎么优化

1. 减小 JWT 的大小：只包含必要的信息
2. 缓存用户信息：减少每次请求都需要解析 JWT 的开销。
3. 实现 Token 的刷新机制：减少用户频繁登录的次数，提高用户体验。
4. 限制 Token 的访问权限：可以减少对数据库的访问次数，提高性能。
5. 使用 CDN 和反向代理：可以使用 CDN（内容分发网络）和反向代理来缓存和分发 JWT Token，减轻服务器的负载，提高响应速度。

16. 如何防止jwt传输途中被截取

1. 使用 HTTPS 加密传输：最有效的方式是通过使用 HTTPS 协议来加密通信。HTTPS 使用了 TLS/SSL 加密技术
2. 避免在 URL 中传输 JWT：不要将 JWT 直接作为 URL 参数传递，因为 URL 参数可能会被记录在日志中或者在浏览器历史记录中留下痕迹，增加了被截取的风险。而是应该将 JWT 放在 HTTP 头部的 Authorization 字段中进行传输。
3. 实现 Token 的签名验证：在服务器端对接收到的 JWT 进行签名验证，确保 JWT 的完整性。
4. 使用短期有效的 JWT
5. 实现 Token 的刷新机制
6. 额外的安全层：在 JWT 中添加额外的安全层，如 CSRF Token，防止 CSRF 攻击；或者在敏感操作中使用双因素身份验证等。

17. JWT缺点

1. 无法撤销：一旦 JWT 被签发，除非它达到了过期时间，否则它就是有效的。
2. 体积较大：JWT 包含了一些额外的信息，如标头、声明和签名等
3. 无法进行会话管理：无法像传统的基于会话的身份验证那样进行会话管理，如主动注销或者强制用户重新验证。
4. 安全性依赖于密钥安全性
5. 不适用于敏感信息存储

18. JWT能够保证安全性吗？

Or 保证token存储在本地安全？

JWT 本身并不能完全保证安全性，它只是一种规范和标准，用于生成和传递令牌。安全性取决于如何使用 JWT 以及其他安全措施的配合。如：

1. 使用安全的存储机制：选择适合的存储机制来存储 Token，如浏览器的本地存储（如 Local Storage 或者 Session Storage）、HTTP Only Cookie 等
2. 服务端管理好密钥
3. 定期更新令牌
4. 限制令牌访问范围
5. HTTPS加密传输
6. 避免在url中传递敏感信息
7. 避免XSS（跨站脚本）攻击

19. 如何保证token过期刷新

使用刷新令牌：除了访问令牌（Access Token）外，还可以为用户颁发一个刷新令牌（Refresh Token）

在访问令牌过期之前，每次访问可以通过向服务器发送特定的请求来刷新令牌

20. 无状态登录和有状态登录的区别

1. 无状态登录（Stateless Login）：
   1. 在无状态登录中，服务器不需要保存用户的会话状态。客户端在之后的每次请求中都会将该 JWT 作为身份凭证发送给服务器，服务器只需要验证 JWT 的有效性，而不需要在服务器端保存任何会话信息。
   2. 由于服务器不保存会话状态，因此无状态登录适用于分布式和跨域应用环境，具有更好的可扩展性和性能。
2. 有状态登录（Stateful Login）：
   1. 在有状态登录中，服务器需要在服务器端保存用户的会话状态。每次用户进行身份验证时，服务器会将用户的会话信息保存在服务器端，并返回一个会话标识符（Session ID）给客户端。
   2. 客户端在之后的每次请求中都会将会话标识符发送给服务器，服务器通过会话标识符来识别用户的会话状态，从而进行身份验证和授权。

21. 退出登录、注册怎么通过JWT实现？

1. 退出登录：退出登录通常意味着销毁客户端保存的 JWT 令牌。
   1. 客户端发送一个特殊的请求，如注销请求，到服务器端。
   2. 服务器端收到注销请求后，将相应用户的 JWT 令牌加入一个黑名单列表或者删除相应的令牌信息。
   3. 客户端收到服务器的响应后，删除本地存储的 JWT 令牌，使用户被注销。
2. 注册：
   1. 客户端向服务器发送注册请求，包含新用户的注册信息，如用户名和密码等。
   2. 服务器接收到注册请求后，验证注册信息的合法性，并创建新用户。随后，服务器生成相应用户的 JWT 令牌，并将其返回给客户端。
   3. 客户端收到服务器返回的 JWT 令牌后，将其保存在本地，以便在以后的请求中使用。

22. 如果用户更改了密码，如何处理jwt令牌

让令牌失效：

1. 强制用户重新登录：当用户更改密码后，服务器端直接删除用户之前的所有 JWT 令牌，并要求用户重新登录。
2. 使用密码加盐：在用户更改密码时，修改用户的密码同时也修改密码的盐值。
3. 添加版本号或时间戳：在 JWT 的负载中添加一个版本号或者时间戳字段，表示用户的密码版本或者密码修改时间。

23. 怎么让JWT提前失效

1. 设置过期时间（exp）：JWT 的playLoad中包含了一个名为 “exp” 的声明，可以设置
2. 撤销令牌：维护一个令牌撤销列表，当用户注销或者改变了密码时，将相应的令牌加入到撤销列表中，以使这些令牌失效。
3. 使用刷新令牌：刷新令牌有更长的有效期，可以获取访问令牌。一旦刷新令牌失效或者被使用，之前颁发的访问令牌就会提前失效。

24. 强行让JWT失效会发生什么事情？

JWT通常被设计为服务器不需要在数据库中存储任何关于令牌的信息

然而，如果强行让 JWT 失效，通常需要在服务器端维护一个令牌的黑名单或者撤销列表，这就涉及到在数据库或者其他持久化存储中存储令牌信息，违背了 JWT 无状态的初衷。

25. 除了JWT还有没有别的方案，它们之间的优缺点分别是什么

1. Cookie + session
2. OAuth：通常用于实现第三方登录
3. JWT：实现无状态的用户身份验证和授权，适用于需要在不同的应用之间传递用户身份信息的情况，如单点登录、跨域认证等。

26. 介绍一下单点登录，jwt怎么实现单点登录？

单点登录（Single Sign-On，简称 SSO）是一种身份认证的机制，允许用户通过一次登录，就能够访问多个相关的系统或服务。

在一个认证中心进行登录，获取JWT，然后访问其他服务都将这个JWT作为身份凭证发送给服务端

而且JWT可以实现自定义声明，适用于单点登录

27. 跨域是什么，为什么会有跨域问题？

跨域（Cross-Origin）是指在 Web 开发中，当一个域名下的文档或脚本试图去请求另一个域名下的资源时，就会产生跨域问题。

跨域流程：

1. 用户登录：用户在任意一个服务器上进行登录，登录成功后，服务器生成 JWT 并将其返回给客户端。
2. JWT 传递：客户端收到 JWT 后，将其保存在本地，通常是在浏览器的本地存储（如 Local Storage）或者 Cookie 中。
3. 跨域请求：用户在其他服务器上进行访问时，客户端将 JWT 放入请求头中（通常是 Authorization 头），发送到另一个服务器。
4. JWT 验证：另一个服务器接收到请求后，验证 JWT 的签名和有效期。如果验证通过，则说明用户已经通过认证，可以继续处理请求；否则，返回相应的错误信息。
5. 响应处理：另一个服务器处理完请求后，可以生成新的 JWT 并返回给客户端，以便客户端在下次请求时继续使用。

跨域问题产生的原因主要有以下几点：

1. 同源策略（Same-Origin Policy）：同源策略是浏览器的一项安全策略，限制了一个域下的文档或脚本与另一个域下的资源进行交互。同源策略规定了只有当请求的协议、主机和端口号完全一致时，才允许进行跨域请求，否则就会产生跨域问题。
2. 安全性考虑：跨域请求可能会带来安全隐患，比如跨站脚本（XSS）攻击和跨站请求伪造（CSRF）攻击等。浏览器为了保护用户的信息安全，因此默认情况下会阻止跨域请求。
3. 浏览器限制：浏览器出于安全考虑，对跨域请求进行了限制，包括不允许跨域读取 Cookie、不允许跨域访问 DOM 和不允许跨域发送 AJAX 请求等。

跨域问题会影响到 Web 开发中的很多场景，比如跨域 AJAX 请求、跨域资源共享（CORS）、跨文档消息传递（PostMessage）等。为了解决跨域问题，通常可以采取以下几种方法：

• CORS（Cross-Origin Resource Sharing）：通过服务端设置响应头来允许跨域请求，从而在客户端浏览器上解决跨域问题。
  • 使用 @CrossOrigin 注解
  • 全局配置 CORSpublic class CorsConfig implements WebMvcConfigurer
  • 通过配置文件配置 CORS
• WebSocket：WebSocket 不受同源策略的限制，可以通过建立 WebSocket 连接来实现跨域通信。

28. 企业有多个服务器多个域名怎么实现jwt？除了jwt还有哪些能实现跨域认证

1. 单点登录
2. JWT包含域名信息
3. 使用统一的认证服务器，负责用户身份认证和生成 JWT。所有的服务器都向该认证服务器发送认证请求，验证用户身份后生成 JWT 返回给客户端。

其他跨域认证方法：

1.OAuth2.0

29. 场景题：设计一个手机端扫码登录电脑端的的功能

1. 生成登录二维码：
   1. 在电脑端的登录页面上生成一个登录二维码。
   2. 二维码内容可以是一个唯一的标识符，代表着当前登录会话的标识。
2. 手机端扫码
3. 验证二维码：
   1. 手机端扫描到二维码后，将二维码的内容发送到服务器进行验证。
   2. 服务器验证二维码的有效性，并确定该二维码对应的登录会话是否有效。
4. 登录确认：
   1. 如果二维码有效，服务器返回登录确认信息给手机端。
   2. 手机端接收到确认信息后，提示用户确认登录操作。
5. 登录处理：
   1. 用户在手机端确认登录操作后，手机端发送登录请求给服务器，携带用户身份信息。
   2. 服务器验证用户身份信息，并在后台完成登录流程。
6. 登录状态同步：
   1. 服务器在登录成功后，在电脑端和手机端均生成对应的登录状态信息（如登录令牌或者会话标识）。
   2. 电脑端和手机端均保存登录状态信息，以便在后续的操作中进行身份验证和授权。
7. 登录完成：
   1. 登录完成后，电脑端和手机端均显示登录成功的提示。
   2. 用户可以在电脑端和手机端自由操作，并保持登录状态的同步。

30. 其他：websock…

如何自定义登录接口以及jwt过滤器

websocket 轮询什么的

扩展：集成 Sa-token 实现角色认证和权限认证，并使用Redis集成进行缓存，添加API签名参数增强

Sa-Token

oauth2.0 vs sso，jwt 双token

为什么不选择SpringSecurity 、Shiro

1. 需求能否被胜任：单点登录, 身份切换, 等等等等, 以及可能产生的需求, auth2, 动态鉴权
2. 上手难度小：SaToken最简单, Shiro中规中矩, SpringSecurity最繁琐
3. 友好程度：文档是否友好, demo是否完善, 以及各大论坛博客文章错误内容多不多. 如果是中文的话SaToken更友好, 英文则SpringSecurity

登录的逻辑，需要从请求发到服务端开始，说清楚springmvc的处理流程，然后在到业务处理，包括方法的返回值都要说清楚。

API签名参数