本文由 简悦 SimpRead 转码， 原文地址 www.ruanyifeng.com

JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案

一、跨域认证的问题

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

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

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

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

一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。

另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

二、JWT 的原理

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

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

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

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

三、JWT 的数据结构

实际的 JWT 大概就像下面这样。

JSON Web Token - 图1

它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。

JWT 的三个部分依次如下。

  • Header（头部）
  • Payload（负载）
  • Signature（签名）

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

 Header.Payload.Signature

JSON Web Token - 图2

3.1 Header

Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。

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

alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；
typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

最后，将上面的 JSON 对象使用 Base64URL 算法转成字符串。就得到JWT的第一部分
base64是一种转换算法，Base64使用64个字符，把任何字符转换为之后，都在这64个字符范围内，可以把一些不可见字符都转换为这64个字符，使其变为可见字符，便于网络传输。而且由于base编码需要先获取资源的二进制值，所以base编码可以转换任何数据，如将图片转换为文本的形式，这样就可以在文本里传输图片了
二进制 字符编码

3.2 Payload

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

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

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

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

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

这个 JSON 对象也要使用 Base64URL 算法转成字符串。得到JWT的第二部分

3.3 Signature

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

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

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用 “点”（.）分隔，就可以返回给用户。
签名是服务端用于验证消息在传递过程中有没有被更改，服务端在收到用户提交的jwt之后，会拿出jwt的第一，第二部分，按照上面的公式算出签名，和jwt中的第三部分进行对比；并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
看一张官网的图就明白了：
image.png

3.4 Base64URL

前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

四、JWT 的使用方式

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

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

 Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

JWT 校验原理

JSON Web Token - 图4。 当服务器收到客户端的 token 后，解析前两部分得到 header 以及 payload，并使用 header 中的算法与 服务端本地私有 secret 进行签名，判断与 jwt 中携带的签名是否一致。

jwt 前两部分是对 header 以及 payload 的 base64 编码；服务端接收到请求之后，
从 Token 中拿出 header 和 payload ，对header进行base64解码，得到header中的签名算法是哪个
然后通过header中的签名算法将 header 和 payload 和 保存在服务端的秘钥secret值按照下面的公式进行计算得出 Signature 的内容，与Token中的第三部分，也就是Signature去比较，如果一致则验证通过，反之则失败。

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

五、JWT 的 优缺点

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

（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。

（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。

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

（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

5. 基于Token的身份认证 与 基于服务器的身份认证

5.1. 基于服务器的身份认证

在讨论基于Token的身份认证是如何工作的以及它的好处之前，我们先来看一下以前我们是怎么做的：
HTTP协议是无状态的，也就是说，如果我们已经认证了一个用户，那么他下一次请求的时候，服务器不知道我是谁，我们必须再次认证
传统的做法是将已经认证过的用户信息存储在服务器上，比如Session。用户下次请求的时候带着Session ID，然后服务器以此检查用户是否认证过。
这种基于服务器的身份认证方式存在一些问题：
Sessions : 每次用户认证通过以后，服务器需要创建一条记录保存用户信息，通常是在内存中，随着认证通过的用户越来越多，服务器的在这里的开销就会越来越大。
Scalability : 由于Session是在内存中的，这就带来一些扩展性的问题。
CORS : 当我们想要扩展我们的应用，让我们的数据被多个移动设备使用时，我们必须考虑跨资源共享问题。当使用AJAX调用从另一个域名下获取资源时，我们可能会遇到禁止请求的问题。
CSRF : 用户很容易受到CSRF攻击。

5.2. JWT与Session的差异

相同点是，它们都是存储用户信息；然而，Session是在服务器端的，而JWT是在客户端的。
Session方式存储用户信息的最大问题在于要占用大量服务器内存，增加服务器的开销。
而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。
Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
JSON Web Token - 图5

5.3. 基于Token的身份认证是如何工作的

基于Token的身份认证是无状态的，服务器或者Session中不会存储任何用户信息。

没有会话信息意味着应用程序可以根据需要扩展和添加更多的机器，而不必担心用户登录的位置。

虽然这一实现可能会有所不同，但其主要流程如下：

  • 用户携带用户名和密码请求访问
  • 服务器校验用户凭据
  • 应用提供一个token给客户端
  • 客户端存储token，并且在随后的每一次请求中放在header中发送到服务器
  • 服务器校验token并返回数据(服务器无需存储token，只需要解密即可)

注意：

  • 每一次请求都需要token
  • Token应该放在请求header中

  • 我们还需要将服务器设置为接受来自所有域的请求，用Access-Control-Allow-Origin: *

    5.4. 用Token的好处

    无状态和可扩展性：Tokens存储在客户端。完全无状态，可扩展。我们的负载均衡器可以将用户传递到任意服务器，因为在任何地方都没有状态或会话信息。
    安全：Token不是Cookie。（The token, not a cookie.）每次请求的时候Token都会被发送。而且，由于没有Cookie被发送，还有助于防止CSRF攻击。即使在你的实现中将token存储到客户端的Cookie中，这个Cookie也只是一种存储机制，而非身份认证机制。没有基于会话的信息可以操作，因为我们没有会话!

    还有一点，token在一段时间以后会过期，这个时候用户需要重新登录。这有助于我们保持安全。还有一个概念叫token撤销，它允许我们根据相同的授权许可使特定的token甚至一组token无效。

    5.5. JWT与OAuth的区别

  • OAuth2是一种授权框架 ，JWT是一种认证协议

  • 无论使用哪种方式切记用HTTPS来保证数据的安全性
  • OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)，而JWT是用在前后端分离, 需要简单的对后台API进行保护时使用。

jwt常用场景

https://mp.weixin.qq.com/s/ZD9u8Em8UHFmjag3CGd2tQ#tocbar—1ubi0gr

邮箱验证

很多网站在注册成功后添加了邮箱验证功能，功能实现：用户注册成功后，完善邮箱，服务端会给用户邮箱发一个链接，用户点开链接校验成功，这个功能使用 JWT 是个不错的选择。

// 把邮箱以及用户id绑定在一起，设置生效时间
const code = jwt.sign({ email, userId }, secret, { expiresIn: 60 \* 30 })

// 在此链接校验验证码
const link = \`https://www.inode.club/code=${code}\`

做那些短期的验证需求 (强烈推荐的场景)

比如在 BFF 层，用 JWT 去验证传递一些数据还是不错的选择，可以把有效时间设置的短一些，过期了就需要重新去请求，我这么直接表述你可能还不太懂，举个现实生活中的例子。

放到一些系统集成的应用场景中，例如我前面说的 BFF 中其实 JWT 更适合一次性操作的认证：

服务 B 你好, 服务 A 告诉我，我可以操作 , 这是我的凭证（即 JWT ）

在这里，服务 A 负责认证用户身份（类似于上例班主任批准请假），并颁布一个很短过期时间的 JWT 给浏览器（相当于上例的请假单），浏览器（相当于上例请假的我们）在向服务 B 的请求中带上该 JWT，则服务 B（相当于上例的任课教师）可以通过验证该 JWT 来判断用户是否有权限执行该操作。通过这样，服务 B 就成为一个安全的无状态的服务。

个人还是认为 JWT 更适合做一些一次性的安全认证，好多其他场景考虑多了之后又做回了 session，传统的 cookie-session 机制工作得更好，但是对于一次性的安全认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小。上面的邮箱验证其实也是一次性的安全认证。

跨域认证

因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）。JWT 确实是跨域认证的一个解决方案，但是对于跨域场景时要注意一点。 客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

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

Authorization: Bearer 另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

登陆验证

登陆验证: 不需要控制登录设备数量以及注销登陆情况，无状态的 jwt 是一个不错的选择。具体实现流程，可以看上文中的校验原理，校验原理使用的登陆验证例子。

当需求中出现控制登陆设备数量，或者可以注销掉用户时，可以考虑使用原有的 session 模式，因为针对这种登陆需求，需要进行的状态存储对 jwt 添加额外的状态支持，增加了认证的复杂度，此时选用 session 是一个不错的选择。 针对上面的特殊需求，可能也有小伙伴仍喜欢使用 jwt ，补充一下特殊案例

注销登陆

用户注销时候要考虑 token 的过期时间。

  • session: 只需要把 user_id 对应的 token 清掉即可 ;
  • jwt: 使用 redis，需要维护一张黑名单，用户注销时把该 token 加入黑名单，过期时间与 jwt 的过期时间保持一致。

用户登陆设备控制
  • session: 使用 sql 类数据库，维护一个用户验证 token 表，每次登陆重置表中 token 字段，每次请求需要权限接口时，根据 token 查找 user_id(也可以使用 redis 维护 token 数据的存储)
  • jwt: 假使使用 sql 类数据库，维护一个用户验证 token 表，表中添加 token 字段，每次登陆重置 token 字段，每次请求需要权限接口时，根据 jwt 获取 user_id，根据 user_id 查用户表获取 token 判断 token 是否一致。(也可以使用 redis 维护 token 数据的存储)

适合做那些事来讲的，其实也就是针对 JWT 的优势来说的，还有一些辩证性的理解。接下来说说 JWT 的缺点。