背景
目前我们的服务在用户登录时，会先通过登录接口进行密码校验。一旦验证成功，后端会利用UUID生成一个独特的令牌（token），并将其存储在Redis缓存中。同时，前端也会将该令牌保存在本地。在后续的接口请求中，用户必须提供这个令牌以进行身份验证。
为了深入了解和掌握项目登录模式的原理，我特意整理了常见的登录校验模式以及它们的优缺点。
登录校验模式
Session校验
基于 Session 的方案中，登录成功后，服务端将用户的身份信息存储在 Session 里，并将 Session ID 通过 Cookie 传递给客户端。后续的数据请求都会带上 Cookie，服务端根据 Cookie 中携带的 Session ID 来得辨别用户身份。
Token校验
而在基于 Token 的方案中，服务端根据用户身份信息生成 Token，发放给客户端。客户端收好 Token，并在之后的数据请求中带上 Token，服务端接到请求后校验并解析 Token 得出用户身份
JSON Web Token
JWT用来安全地表示要在双方之间传递的声明，能够通过 URL 传输。JWT的好处是无状态、轻量级，且不需要存储在服务端，因为它可以在客户端自包含所有必要的信息。
Token 格式
JWT 中的 Token 分为 3 部分，Header、Payload 与 Signature
格式为：Header.Payload.Signature
- Header表示 Token 相关的基本元信息，如 Token 类型、加密方式（算法）等，具体如下（alg是必填的，其余都可选）：
typ：Token type
cty：Content type
alg：Message authentication code algorithm
- Payload表示 Token 携带的数据及其它 Token 元信息，规范定义的标准字段如下：
iss：Issuer，签发方
sub：Subject，Token 信息主题（Sub identifies the party that this JWT carries information about）
aud：Audience，接收方
exp：Expiration Time，过期时间
nbf：Not (valid) Before，生效时间
iat：Issued at，生成时间
jti：JWT ID，唯一标识
这些字段都是可选的，Payload 只要是合法 JSON 即可
- Signature签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
jwt优缺点
JWT（JSON Web Token）的优点包括：
-
实现分布式单点登录：JWT使得用户身份验证变得简单直接，特别是在多个系统之间需要共享用户信息的情况下。
减轻服务器负担：由于数据实际上保存在客户端，这样可以减少服务器端的存储压力。 -
灵活的数据交换方式：JWT可以作为HTTP请求的一部分，便于在API中传递和验证用户身份。
支持自定义扩展：JWT可以包含自定义的扩展字段，以满足特定的安全需求或业务逻辑。 -
设置过期时间：JWT允许设置过期时间，从而提供了一种机制来确保安全性并防止未授权访问。
JWT的缺点包括：
-
依赖客户端行为：由于数据保存在客户端，如果客户端不当操作，可能会带来安全隐患。
-
难以调整过期时间：由于数据保存在客户端，对于过期时间的调整可能不够灵活，尤其是在没有统一管理客户端的情况下。
项目实践
在实际应用中我们是综合了上诉的两种模式，采用登陆时生成一个token，将token和用户绑定缓存到redis中。然后在校验时除了校验token是否有效（redis中是否含义token外），还会校验用户账户跟登陆账户是否一致。
