官方英文原文在这里https://jwt.io/introduction/，我只是顺手翻译一下，如有不对的地方欢迎留言讨论~

什么是JSON Web Token?

JSON Web Token(JWT) 是一个开放标准（RFC 7519），它定义了一种协议，以自包含的JSON格式在两点之间安全地传输信息。被传输的信息是可以被证实、被信任的，因为它使用了数字签名。JWT能够通过使用密匙（HMAC算法）或者一个公钥/秘钥对（RSA算法）来进行数字签名。

让我们更深入地解释这个定义的一些概念。

简洁: 因为JWT的长度相对来说更短, 它可以通过URL、POST参数或者包含在HTTP头里进行传输，而且，更短的长度意味着更快的传输速度。

自包含: payload字段包含了当前用户的所有所需信息，这样只要第一次查询数据库就行，后面不用再查询数据库了。

什么时候你该使用JSON Web Tokens?

下面是JWT的常见使用场景：

鉴权：这是最常见的使用JWT的场景。一旦用户登入了，之后的每次请求都会包含JWT，允许用户去访问被当前token许可的路由、服务和资源。因为非常小的开销以及很容易被用于跨域，如今JWT被广泛用于单点登录。

信息交换：如果你需要安全地在两点之间传输信息，JSON Web Tokens 是一个不错的选择。因为JWT能够被签名—例如，使用公钥/私钥对—你可以确认发送者的身份没有造假，而且，因为签名是由header和payload字段计算的，你也可以验证传输的内容没有被篡改。

JSON Web Token的格式是怎样的？

JSON Web Token由三部分组成，他们由点号（.）隔开，分别是：

Header

Payload

Signature

因此，一个典型的JWT看起来就像下面这样。

xxxxx.yyyyy.zzzzz

让我们来分解这三个部分。

Header

header包含两部分：token的类型，当然就是JWT了，以及使用的哈希算法，例如HMAC SHA256 或者 RSA。

例如：

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

然后，这段json由Base64Url加密，生成JWT的第一部分。

Payload

token的第二个部分是payload，它声明一个实体的相关信息（通常都是用来描述当前用户）以及附加的元数据。有三种类型的声明：注册声明、公有声明以及私有声明。

注册声明：注册声明是标准中注册的声明，非强制性的但是推荐去使用，因为他们很有效而且通用。比如：iss (发行者)、exp (过期时间)、sub (主题)、aud (受众)、 以及 更多。注意声明的名字只有三个字母，因为JWT的初衷就是要尽量紧凑、简洁。

公有声明: 公有声明可以由使用JWT的人来定义，但是为了避免冲突，它们应该在IANA JSON Web Token Registry定义， 或者被定义为包含有冲突的名称空间的URI。

私有声明: 私有声明是由通信双方共同约定的、自定义的声明，它们被用来在双方共享信息，它们既不是注册声明，也不是公有声明。

payload示例：

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

然后，payload由Base64Url加密，生成JWT的第二部分。

签名

在创建签名之前，你必须已经知道经过加密的header、payload、一个密匙以及在header里指定的加密算法。例如，你想使用HMAC SHA256算法，签名需要按下列步骤创建：

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

签名被用来证明发送JWT者的身份没有造假，以及确保发送的内容不会在传输过程中被篡改。

组合所有部分

输出是三段被点号（.）分隔的Base64字符串，在HTML和HTTP环境里很容易去传输。和基于XML的标准，例如SAML比起来，JWT更加紧凑。

下图展示了一段JWT（源站图片加载不出来，我就不贴图了~ *1）

如果你想要学习JWT并且练习这些概念，你可以使用 jwt.io Debugger 去解密、验证以及生成 JWT。

JSON Web Tokens 是如何工作的?

在鉴权过程中,当用户使用它们的身份证明成功登陆，与传统的在服务器创建一个session并返回一个cookie的方式不同，一个JSON Web Token将会返回给用户，并且必须被保存在客户端，（一般来说用local storage，不过也可以用cookies）。

无论什么时候，当用户想访问一个被保护的路由或者资源，UA应该包含此JWT，典型的做法是在Authorization header使用Bearer schema，此Authorization header的内容看起来大概是这样：

Authorization: Bearer <token>

这是一种无状态的鉴权机制，因为服务器内存并没有保存用户状态，服务器上受保护的路由将会检查Authorization header里的JWT是否有效，如果有效，用户将被允许访问受保护的资源。由于JWT是自包含的，所有需要的信息都在里面，减少了多次查询数据库带来的性能开销。

这使你能够完全依赖无状态的数据api，甚至向下游服务发出请求。具体是哪些域名在为你提供API并不重要，所以跨站资源共享（CORS）问题并不存在，因为JWT并不使用cookies。下面的图表显示了JWT的工作流程。（源站图片加载不出来，我就不贴图了~ *2）

为什么我们应该使用 JSON Web Tokens?

通过JWT与 Simple Web Tokens (SWT) 和 Security Assertion Markup Language Tokens (SAML) 的对比，我们来讨论一下使用JWT的好处。

因为JSON比XML更紧凑，JWT比SAML更加紧凑，这使得JWT更适合在HTML、HTTP环境下传输。

至于安全方面，SWT只能通过使用HMAC算法的共享密钥进行对称签名。不管怎样，JWT和SAML可以以X.509证书的形式使用公钥/私钥对去签名。与签名JSON的简单性相比， 在没有介绍模糊的安全漏洞的情况下，使用XML数字签名来签署XML是非常困难的。

在绝大部分编程语言中，JSON解析器都是大同小异，因为它们可以直接映射到对象。相反的，XML并没有一个自然的文档转对象的映射，这使得使用JWT比使用SAML更容易。

考虑使用场景，JWT被用于互联网，突出了跨平台客户端尤其是移动端上，处理JWT的便捷性。

加密后，JWT和SAML的长度对比
（源站图片加载不出来，我就不贴图了~ *3）

如果你想阅读更多有关JWT的知识，或者想用JWT去完成你的应用的鉴权，请转到Auth0的JSON Web Token landing page