JWT总结

概述

JSON Web Token（JWT）是目前最流行的跨域身份验证解决方案之一

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

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 (…)

Simply put, JWT is a sequence of characters in JSON format (https://www.json.org/) encoded in JWS (JSON Web Signature) or JWE (JSON Web Encryption) structure. Besides, each of these options must be serialized in a compact way (one of the two serializations in JWS and JWE). Most often you can see JWS, and it is this structure that is popularly called JWT. In turn, “claim” is usually a simple pair of “key” : “value”.

JWT是为了网络应用环境间传递声明而执行的一种基于JSON的开发标准（RFC 7519），该token设计紧凑且安全，特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者之间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，该token也可以直接被用于认证，也可被加密。

什么情况下使用JWT合适？

• 授权，解决单点登录问题
• 信息交换

**授权：**这是最常见的使用场景，解决单点登录问题。因为JWT使用起来轻便，开销小，服务端不用记录用户状态信息（无状态），所以使用比较广泛； **信息交换：**JWT是在各个服务之间安全传输信息的好方法。因为JWT可以签名，例如，使用公钥/私钥对儿 - 可以确定请求方是合法的。此外，由于使用标头和有效负载计算签名，还可以验证内容是否未被篡改。

起源

说起JWT，就先说说基于传统session认证的方案以及瓶颈

当浏览器向服务器发送登录请求时，验证通过之后，会将用户信息存入seesion中，然后服务器会生成一个sessionId放入cookie中，随后返回给浏览器。当浏览器再次发送请求时，会在请求头部的cookie中放入sessionId，将请求数据一并发送给服务器。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RO25Fp3k-1667897660802)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202210281722653.png)]

服务器就可以再次从seesion获取用户信息，整个流程完毕！

通常在服务端会设置seesion的时长，例如 30 分钟没有活动，会将已经存放的用户信息从seesion中移除。

session.setMaxInactiveInterval(30 * 60);

同时，在服务端也可以通过seesion来判断当前用户是否已经登录，如果为空表示没有登录，直接跳转到登录页面；如果不为空，可以从session中获取用户信息即可进行后续操作。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nBn3SLD5-1667897660803)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202210281736062.png)]

在单体应用中，这样的交互方式，是没啥问题的。

但是，假如应用服务器的请求量变得很大，而单台服务器能支撑的请求量是有限的，这个时候就容易出现请求变慢或者OOM。

解决的办法，要么给单台服务器增加配置，要么增加新的服务器，通过负载均衡来满足业务的需求。

如果是给单台服务器增加配置，请求量继续变大，依然无法支撑业务处理。显而易见，增加新的服务器，可以实现无限的水平扩展。

但是增加新的服务器之后，不同的服务器之间的sessionId是不一样的，可能在A服务器上已经登录成功了，能从服务器的session中获取用户信息，但是在B服务器上却查不到session信息，此时肯定无比的尴尬，只好退出来继续登录，结果A服务器中的session因为超时失效，登录之后又被强制退出来要求重新登录，想想都挺尴尬～～

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-izTKFgRm-1667897660804)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202210281756767.png)]

将各个应用程序与内存数据库redis相连，对登录成功的用户信息进行一定的算法加密，生成的ID被称为token，将token还有用户的信息存入redis；等用户再次发起请求的时候，将token还有请求数据一并发送给服务器，服务端验证token是否存在redis中，如果存在，表示验证通过，如果不存在，告诉浏览器跳转到登录页面，流程结束。

token方案保证了服务的无状态，所有的信息都是存在分布式缓存中。基于分布式存储，这样可以水平扩展来支持高并发。

当然，现在springboot还提供了session共享方案，类似token方案将session存入到redis中，在集群环境下实现一次登录之后，每个服务器都可以获取到用户信息。

什么是JWT

上文中，我们谈到的session还有token的方案，在集群环境下，他们都是靠第三方缓存数据库redis来实现数据的共享。

那有没有一种方案，不用缓存数据库redis来实现用户信息的共享，以达到一次登录，处处可见的效果呢？

答案肯定是有的，就是我们今天要介绍的JWT！

JWT全称JSON Web Token，实现过程简单的说就是用户登录成功之后，将用户的信息进行加密，然后生成一个token返回给客户端，与传统的session交互没太大区别。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wNoF1qR8-1667897660804)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202210281757485.png)]

唯一的不同点就是：token存放了用户的基本信息，更直观一点就是将原本放入redis中的用户数据，放入到token中去了！

这样一来，客户端、服务端都可以从token中获取用户的基本信息，既然客户端可以获取，肯定是不能存放敏感信息的，因为浏览器可以直接从token获取用户信息。

JWT具体长什么样

JWT是由三段信息构成的，将这三段信息文本用.链接一起就构成了JWT字符串

对象为一个很长的字符串，字符之间通过"."分隔符分为三个子串。注意JWT对象为一个长字串，各字串之间也没有换行符，一般格式为：xxxxx.yyyyy.zzzzz 。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

• 第一部分：我们称它为头部（header），用于存放token类型和加密协议，一般都是固定的；
• 第二部分：我们称其为载荷（payload），用户数据就存放在里面；
• 第三部分：是签证（signature），主要用于服务端的验证；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f9FoxDtz-1667897660805)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202211081556816.png)]

header

JWT的头部承载两部分信息：

• 声明类型，这里是JWT；
• 声明加密的算法，通常直接使用 HMAC SHA256；

完整的头部就像下面这样的JSON：

{
  'typ':'JWT'
  'alg':'HS256'
}

使用base64加密，构成了第一部分。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号

载荷就是存放有效信息的地方，这些有效信息包含三个部分：

• 标准中注册的声明；
• 公共的声明；
• 私有的声明；

其中，标准中注册的声明 (建议但不强制使用)包括如下几个部分 ：

• iss: jwt签发者；
• sub: jwt所面向的用户；
• aud: 接收jwt的一方；
• exp: jwt的过期时间，这个过期时间必须要大于签发时间；
• nbf: 定义在什么时间之前，该jwt都是不可用的；
• iat: jwt的签发时间；
• jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击；

公共的声明部分：公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息，但不建议添加敏感信息，因为该部分在客户端可解密。

私有的声明部分：私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

定义一个playload除以上默认字段外，我们还可以自定义私有字段，如下例：

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

然后将其进行base64加密，得到Jwt的第二部分：

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。 这个 JSON 对象也要使用 Base64URL 算法转成字符串。 代码样例如下:

JWT.create().withHeader(map) // header
                .withClaim("iss", "Service") // payload
                .withClaim("aud", "APP")
                .withIssuedAt(iatDate) // sign time
                .withExpiresAt(expiresDate) // expire time
                .withClaim("name", "cy") // payload
                .withClaim("user_id", "11222");

signature

Signature 部分是对前两部分的签名，防止数据篡改。 首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

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

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就构成整个JWT对象TOKEN， 就可以返回给用户。

前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。 JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

• header (base64后的)；
• payload (base64后的)；
• secret (密钥);

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pR3ulkTk-1667897660805)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202210292022055.png)]

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

javascriptvar encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
var signature = HMACSHA256(encodedString, '密钥');

加密之后得到signature签名信息

TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用.连接成一个完整的字符串，就构成了最终的jwt：

//jwt最终格式eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

这个只是通过javascript实现的一个演示，JWT的签发和密钥的保存都是在服务端来完成。

secret用来进行jwt的签发和jwt的验证，所以，在任何场景都不应该流露出去。

客户端接收服务器返回的JWT，将其存储在Cookie或localStorage中。 此后，客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中，就可以自动发送，但是不会跨域，因此一般是将它放入HTTP请求的Header Authorization字段中。

 Authorization: Bearer <token>

当跨域时，也可以将JWT被放置于POST请求的数据主体中。

JWT原理

跨域认证

互联网服务离不开用户认证。一般流程是下面这样：

• 用户向服务器发送用户名和密码。
• 服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
• 服务器向用户返回一个 session_id，写入用户的 Cookie。
• 用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
• 服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。 另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

JWT 的原理

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

 {
 "姓名": "张三",
 "角色": "管理员",
 "到期时间": "2018年7月1日0点0分"
 }

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

区别：

 (1) session 存储在服务端占用服务器资源，而 JWT 存储在客户端
 (1) session 存储在 Cookie 中，存在伪造跨站请求伪造攻击的风险
 (2) session 只存在一台服务器上，那么下次请求就必须请求这台服务器，不利于分布式应用
 (3) 存储在客户端的 JWT 比存储在服务端的 session 更具有扩展性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NWik0Q9v-1667897660806)(https://cdn.jsdelivr.net/gh/huijia-v/pic_cloud/img/202211081551254.png)]

流程说明：
1，浏览器发起请求登陆，携带用户名和密码；
2，服务端验证身份，根据算法，将用户标识符打包生成 token,
3，服务器返回JWT信息给浏览器，JWT不包含敏感信息；
4，浏览器发起请求获取用户资料，把刚刚拿到的 token一起发送给服务器；
5，服务器发现数据中有 token，验明正身；
6，服务器返回该用户的用户资料；

3.4 JWT的6个优缺点

• JWT默认不加密，但可以加密。生成原始令牌后，可以使用改令牌再次对其进行加密。
• 当JWT未加密方法是，一些私密数据无法通过JWT传输。
• JWT不仅可用于认证，还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
• JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
• JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
• 为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输。

总结

JWT相比session方案，因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA、JavaScript、PHP等很多语言都可以使用，而session方案只针对JAVA。

因为有了payload部分，所以JWT可以存储一些其他业务逻辑所必要的非敏感信息。

同时，保护好服务端secret私钥非常重要，因为私钥可以对数据进行验证、解密！

如果可以，请使用https协议！

JWT、JWS、JWE的区别

• JWT(JSON Web Tokens)，jwt长度较小，且可以使用URL传输(URL safe)。不想cookies只能在web环境起作用。 JWT可以同时使用在web环境和RESTfull的接口。

• 对于开发者来说，JWT与另外两种相近的标准:JWS(JSON Web Signature)、JWE(JSON Web Encryption)，容易引起混乱。

• 关于JWT的描述，可以参考RFC7519(https://tools.ietf.org/html/rfc7519)的描述: **JSON Web Token (JWT) **是一个间接地、URL安全的，表现为一组声明，可以在双方之间进行传输。一个JWT的声明，是指经过编码后的一个JSON对象，这个JSON对象可以是一个JSON Web Signature(JWS)结构的荷载(payload)，或者是一个JSON Web Encryption(JWE)结构的明文。允许使用声明进行数字签名，或者通过一个Message Authentication Code(MAC)进行完整性保护可选择是否加密。

  简单来说，JWTs表现为一组被编码为JWS and/or JWE结构的JSON object的声明(Claim).

  换言之，一组JWT声明(就是表现为JSON格式的Claims)被通过JWS结构或者JWE结构(或者同时使用两种)发送，决定于你如何去实现它。所以，当你发送JWT给别人是，它实际上是一个JWT荷载或者JWE荷载。JWS荷载更加常用。

• 关于JWS 顾名思义，JWS模式对这个内容进行了数字化签名。这个内容被用来存放JWT的声明.服务端签名出JWT并且发送到客户端，并在用户成功认证后进行应答。服务器期望客户端在下次请求的时候将JWS作为请求的一部分，发送回服务端。

  如果我们处理的客户端是欺骗者怎么办呢？这就是签名(signature)需要出场的地方了。签名携带了完整的可验证的信息。换句话说，服务器可以确认，接收到的JWT声明里的JWS是没有经过欺骗客户端、中间者进行修改的。 服务端通过验证消息的签名来确保客户端没有修改声明。如果服务端检测到任何修改，可以采取适当的动作(拒绝这次请求或者锁定客户端之类的)。 客户端同样可以验证签名，为了做到这点，客户端也需要服务端的secret(密钥)(如果这个JWT签名是HMAC算法),或者需要服务端对公钥(如果这个WJT是数字化签名)。 特别注意：对于JWS，荷载(声明部分)没有进行加密，所以，不要发送任何敏感信息。

• 关于JWE JWE模式会对内容加密，而不是签名。JWT的声明会被加密。因此JWE带来了保密性。JWE可以被签名并附在JWS里。这样的话就可以同时加密和签名。因此得到了保密性(Confidentiality)、完整性(Integrity)、可认证(Authentication)。

• 那么对于客户端，如何分辨JWS或者JWE呢？ JWS的Header与JWE的Header是不同的，可以通过检查“alg”Header参数的值来区分。如果这个值表现为一个数字签名或者MAC的算法，或者是”none“，则它是一个JWS。 如果它表现为一个 Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, or Direct Encryption algorithm。则它是一个JWE。 还可以通过Header里的“enc”(encryption algorithm)是否存在来判断，如果"enc"这个成员存在的话说明是JWE，否则的话就是JWS.

参考

官方参考

参考连接2