认证方案之初步认识JWT

媒介：

现在越来越多的项目或多或少会用到JWT，为什么会出现使用JWT如许的场景的呢？

假设现在有一个APP，配景是分布式系统。APP的首页模块摆设在上海机房的服务器上，子页面模块摆设在深圳机房的服务器上。此时你从首页登录了该APP，然后跳转到子页面模块。session在两个机房之间不能同步，用户是否须要重新登录？

传统的方式（cookie+session）须要重新登录，用户体验不好。session共享（在多台物理机之间传输和复制session）方式对网络IO的压力大，耽误太长，用户体验也不好。

说到这大家大概会想到，用服务器的session_id存储到cookies中也能做到，为什么非要用token呢？网上有很多文章来比力token和session的优缺点，其实，开辟web应用的话用哪种都行。但如果是开辟api接口，前后端分离，最好使用token，为什么这么说呢，由于session+cookies是基于web的。但是针对 api接口，大概会思量到移动端，app是没有cookies和session的。

Session方式存储用户信息的最大问题在于要占用大量服务器内存，增长服务器的开销。

而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端

原理：

JSON Web Token（缩写 JWT）

JWT 的原理是，服务器认证以后，天生一个 JSON 对象，发回给用户，以后，用户与服务端通信的时间，都要发回这个 JSON 对象。

服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在天生这个对象的时间，会加上签名。

服务器就不生存任何 session 数据了，也就是说，服务器酿成无状态了，从而比力轻易实现扩展。

组合：

JWT 的三个部分依次是：Header（头部）、Payload（负载）、Signature（签名）

写成一行，就是下面的样子。

1. <strong><code >Header.Payload.Signature</code></strong>

复制代码

一、Header

header典范的由两部分构成：token的范例（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）

1. {
2. "alg": "HS256", //alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）
3. "typ": "JWT" //typ属性表示这个令牌（token）的范例（type）
4. }

复制代码

然后用Base64对这个JSON编码就得到JWT的第一部分

二、Payload

JWT的第二部分是payload，它包罗声明（要求）。声明是关于实体(通常是用户)和其他数据的声明

JWT 规定了7个官方字段

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

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子

1. {
2. "sub": "1234567890",
3. "name": "John Doe",
4. "admin": true
5. }

复制代码

1. 注意，不要在JWT的payload或header中放置敏感信息，除非它们是加密的

复制代码

三、Signature

Signature 部分是对前两部分的签名，防止数据篡改。签名是用于验证消息在转达过程中有没有被更改，而且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。

为了得到签名部分，你必须有编码过的header、编码过的payload、一个秘钥，签名算法是header中指定的谁人，然对它们签名即可。按照下面的公式产生签名。

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

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

开始：

一、客户端收到服务器返回的 JWT，可以储存在 Cookie 内里，也可以储存在 localStorage。

以后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 内里自动发送，但是如许不能跨域，以是更好的做法是放在 HTTP 哀求的头信息Authorization字段内里。

1. Authorization: Bearer <token>

复制代码

二、JWT 就放在 POST 哀求的数据体内里，那么跨源资源共享(CORS)将不会成为问题，由于它不使用cookie

1.应用（或者客户端）想授权服务器哀求授权。例如，如果用授权码流程的话，就是/oauth/authorize

2.当授权被许可以后，授权服务器返回一个access token给应用

3.应用使用access token访问受掩护的资源（比如：API）

特点：

1.JWT 默认是不加密，但也是可以加密的。天生原始 Token 以后，可以用密钥再加密一次。

2.JWT 不加密的情况下，不能将机密数据写入 JWT。

3.JWT 的最大缺点是，由于服务器不生存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器摆设额外的逻辑。

4.JWT 自己包罗了认证信息，一旦泄漏，任何人都可以得到该令牌的全部权限。为了减少盗用，JWT 的有效期应该设置得比力短。对于一些比力重要的权限，使用时应该再次对用户进行认证。

注意：

JWT 是 JSON 格式的被加密了的字符串

JWT 的核心是密钥，就是 JSON 数据。这是你关心的，并希望安全转达出去的数据。JWT 怎样做到这一点，并使你信任它，就是加密签名。

被篡改之后

总结：

参考官方文档：JSON Web Tokens

来源：https://www.cnblogs.com/i3yuan/archive/2019/09/14/11519431.html