JWT(JSON Web Token)一种开放的标准规范(RFC 7519),用于在网络上安全的传输信息,通常被用于身份验证。
简单来说,你可以把 JWT 想象成一张小巧的、自包含的电子通行证。这张通行证里面包含了用户的身份信息,就像你在某个俱乐部的会员卡,上面有你的名字、会员等级等信息,拿着这张卡,你就能证明你是谁,享受相应的服务。
# 1.JWT组成
JWT 由三部分组成:头部(Header)、载荷(Payload)和签名(Signature),如下图所示:
- 头部(Header):包含了关于生成该 JWT 的信息以及所使用的算法类型。
- 载荷(Payload):包含了要传递的数据,例如身份信息和其他附属数据。JWT 官方规定了 7 个字段,可供使用:
- iss (Issuer):签发者。
- sub (Subject):主题。
- aud (Audience):接收者。
- exp (Expiration time):过期时间。
- nbf (Not Before):生效时间。
- iat (Issued At):签发时间。
- jti (JWT ID):编号。
- 签名(Signature):使用密钥对头部和载荷进行签名,以验证其完整性。
# 2.JWT工作原理
JWT 工作原理包含三部分:
- 生成 JWT
- 传输 JWT
- 验证 JWT
下面分别来看。
# 1.生成JWT
在用户登录时,当服务器端验证了用户名和密码的正确性后,会根据用户的信息,如用户 ID 和用户名称,加上服务器端存储的 JWT 秘钥一起来生成一个 JWT 字符串,也就是我们所说的 Token,这个 Token 是 Encoded 编码过的,类似于:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Decoded 解码后会得到三部分内容:头部(Header)+载荷(Payload)+签名(Signature)。
- 头部(Header):包含了关于生成该 JWT 的信息以及所使用的算法类型。
- 载荷(Payload):包含了要传递的数据,例如身份信息和其他附属数据。
- 签名(Signature):使用密钥对头部和载荷进行签名,以验证其完整性。
# 2.传输JWT
JWT 通常存储在客户端的 Cookie、LocalStorage、SessionStorage 等位置,客户端在每次请求时把 JWT 放在 Authorization 头中或作为参数传递给服务器端。
# 3.验证JWT
- 服务器端接收到 JWT 的 Token 后,会先将 Token Decoded 解码,之后会得到头部(Header)+载荷(Payload)+签名(Signature)。
- 然后服务器端会使用它本地存储的秘钥,以及头部(Header)中的加密算法和载荷(Payload)中的信息进行重新加密,得到一个新的签名。
- 最后会判断 Token 的真伪,用上一步新生成的签名和 Decoded 解码得到的签名(Signature)进行判断,如果二者一致,则说明当前的 Token 有效性的、完整的,可以执行后续的操作了,否则则返回 Token 错误。当然在这一步判断时,我们通常也要看载荷(Payload)中的过期时间是否有效,如果无效,则需要提示用户重新登录。
# 3.JWT优势
JWT 相较于传统的基于会话(Session)的认证机制,具有以下优势:
- 无需服务器存储状态:传统的基于会话的认证机制需要服务器在会话中存储用户的状态信息,包括用户的登录状态、权限等。而使用 JWT,服务器无需存储任何会话状态信息,所有的认证和授权信息都包含在 JWT 中,使得系统可以更容易地进行水平扩展。
- 跨域支持:由于 JWT 包含了完整的认证和授权信息,因此可以轻松地在多个域之间进行传递和使用,实现跨域授权。
- 适应微服务架构:在微服务架构中,很多服务是独立部署并且可以横向扩展的,这就需要保证认证和授权的无状态性。使用 JWT 可以满足这种需求,每次请求携带 JWT 即可实现认证和授权。
- 自包含:JWT 包含了认证和授权信息,以及其他自定义的声明,这些信息都被编码在 JWT 中,在服务端解码后使用。JWT 的自包含性减少了对服务端资源的依赖,并提供了统一的安全机制。
- 扩展性:JWT 可以被扩展和定制,可以按照需求添加自定义的声明和数据,灵活性更高。
使用 JWT 相较于传统的基于会话的认证机制,可以减少服务器存储开销和管理复杂性,实现跨域支持和水平扩展,并且更适应无状态和微服务架构。