什么是 JWT? 如何基于 JWT 进行身份验证？

什么是 JWT? 如何基于 JWT 进行身份验证？

引用

CSDN

1.

https://blog.csdn.net/double222222/article/details/139721932

JWT（JSON Web Token）是目前最流行的跨域认证解决方案，它是一种基于Token的认证授权机制。JWT不仅提高了系统的可用性和伸缩性，还有效避免了CSRF攻击。本文将详细介绍JWT的组成结构、工作原理以及如何加强JWT的安全性。

什么是 JWT?

JWT（JSON Web Token）是目前最流行的跨域认证解决方案，是一种基于Token的认证授权机制。从JWT的全称可以看出，JWT本身也是Token，一种规范化之后的JSON结构的Token。

Token自身包含了身份验证所需要的所有信息，因此，我们的服务器不需要存储Session信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力。

可以看出，JWT更符合设计RESTful API时的「Stateless（无状态）」原则。

并且，使用Token认证可以有效避免CSRF攻击，因为Token一般是存在在localStorage中，使用JWT进行身份验证的过程中是不会涉及到Cookie的。

我在JWT优缺点分析[1]这篇文章中有详细介绍到使用JWT做身份认证的优势和劣势。

下面是RFC 7519[2]对JWT做的较为正式的定义。

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ——JSON Web Token (JWT)[3]

JWT 由哪些部分组成？

JWT本质上就是一组字串，通过（.）切分成三个为Base64编码的部分：

• Header：描述JWT的元数据，定义了生成签名的算法以及Token的类型。
• Payload：用来存放实际需要传递的数据
• Signature（签名）：服务器通过Payload、Header和一个密钥(Secret)使用Header里面指定的签名算法（默认是HMAC SHA256）生成。

JWT通常是这样的：

xxxxx.yyyyy.zzzzz

示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

你可以在jwt.io[4]这个网站上对其JWT进行解码，解码之后得到的就是Header、Payload、Signature这三部分。

Header和Payload都是JSON格式的数据，Signature由Payload、Header和Secret(密钥)通过特定的计算公式和加密算法得到。

Header

Header通常由两部分组成：

• typ（Type）：令牌类型，也就是JWT。
• alg（Algorithm）：签名算法，比如HS256。

示例：

{
  "alg": "HS256",
  "typ": "JWT"
}

JSON形式的Header被转换成Base64编码，成为JWT的第一部分。

Payload

Payload也是JSON格式数据，其中包含了Claims(声明，包含JWT的相关信息)。

Claims分为三种类型：

• Registered Claims（注册声明）：预定义的一些声明，建议使用，但不是强制性的。
• Public Claims（公有声明）：JWT签发方可以自定义的声明，但是为了避免冲突，应该在IANA JSON Web Token Registry[5]中定义它们。
• Private Claims（私有声明）：JWT签发方因为项目需要而自定义的声明，更符合实际项目场景使用。

下面是一些常见的注册声明：

• iss（issuer）：JWT签发方。
• iat（issued at time）：JWT签发时间。
• sub（subject）：JWT主题。
• aud（audience）：JWT接收方。
• exp（expiration time）：JWT的过期时间。
• nbf（not before time）：JWT生效时间，早于该定义的时间的JWT不能被接受处理。
• jti（JWT ID）：JWT唯一标识。

示例：

{
  "uid": "ff1212f5-d8d1-4496-bf41-d2dda73de19a",
  "sub": "1234567890",
  "name": "John Doe",
  "exp": 15323232,
  "iat": 1516239022,
  "scope": ["admin", "user"]
}

Payload部分默认是不加密的，一定不要将隐私信息存放在Payload当中！！！

JSON形式的Payload被转换成Base64编码，成为JWT的第二部分。

Signature

Signature部分是对前两部分的签名，作用是防止Token（主要是payload）被篡改。

这个签名的生成需要用到：

• Header + Payload。
• 存放在服务端的密钥(一定不要泄露出去)。
• 签名算法。

签名的计算公式如下：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

算出签名以后，把Header、Payload、Signature三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，成为JWT的第三部分。

如何基于 JWT 进行身份验证？

在基于Token进行身份验证的应用程序中，服务器通过Payload、Header和Secret(密钥)创建Token（令牌）并将Token发送给客户端。客户端接收到Token之后，会将其保存在Cookie或者localStorage里面，以后客户端发出的所有请求都会携带这个令牌。

简化后的步骤如下：

1. 用户向服务器发送用户名、密码以及验证码用于登陆系统。
2. 如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的Token。
3. 用户以后每次向后端发请求都在Header中带上这个Token。
4. 服务端检查Token并从中获取用户相关信息。

两点建议：

1. 建议将Token存放在localStorage中，放在Cookie中会有CSRF风险。
2. 请求服务端并携带Token的常见做法是将Token放在HTTP Header的Authorization字段中（Authorization: Bearer Token）。

spring-security-jwt-guide[6]就是一个基于JWT来做身份认证的简单案例，感兴趣的可以看看。

JWT 如何防止 Token 被篡改？

有了签名之后，即使Token被泄露或者解惑，黑客也没办法同时篡改Signature、Header、Payload。

这是为什么呢？因为服务端拿到Token之后，会解析出其中包含的Header、Payload以及Signature。服务端会根据Header、Payload、密钥再次生成一个Signature。拿新生成的Signature和Token中的Signature作对比，如果一样就说明Header和Payload没有被修改。

不过，如果服务端的秘钥也被泄露的话，黑客就可以同时篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后，再重新生成一个Signature就可以。

密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。

如何加强 JWT 的安全性？

1. 使用安全系数高的加密算法。
2. 使用成熟的开源库，没必要造轮子。
3. Token存放在localStorage中而不是Cookie中，避免CSRF风险。
4. 一定不要将隐私信息存放在Payload当中。
5. 密钥一定保管好，一定不要泄露出去。JWT安全的核心在于签名，签名安全的核心在密钥。
6. Payload要加入exp（JWT的过期时间），永久有效的JWT不合理。并且，JWT的过期时间不易过长。
7. ……