想全面理解JWT？一文足矣！

有篇关于JWT的文章，叫“JWT: The Complete Guide to JSON Web Tokens”，写得全面细致。为了自己能更清晰理解并惠及更多人，我把它大致翻译了过来，有些地方稍显冗余就去掉了，但还是接近八千字，感谢原作者！以下是正文：

本文的目标是让你学习JWT的工作原理和细节，以及它在Web应用中能如何帮助你实现用户认证和会话管理功能。那为什么需要深入理解JWT呢？因为这样有助于你：

1. 实现一个基于JWT的认证方案；
2. 各种故障排查：理解错误信息、堆栈信息；
3. 选择第三方库，并理解他们的文档；
4. 自己实现认证方案；
5. 选择和配置第三方认证服务；

即使选择了某个基于JWT的认证方案，同样还需要进行代码编写，编码工作主要是在客户端，但服务端也需要一些。

到本文的结尾，你将深刻理解JWT，包括它基于的加密技术，这种加密技术也广泛使用在其他安全案例中。你还将明白什么时候该用JWT和为什么要使用，同时理解JWT的数据格式，可以使用各种线上工具去分析解决签名上遇到的问题。

为什么是JWT？

相比在内存中存储随机token的用户会话管理方式来说，JWT最大的优势是，它使得将认证逻辑委托给第三方服务成为可能，这些服务包括：

1. 自己开发的、中心化的认证服务器；
2. 能生成JWT的LDAP服务；
3. 完全是外部的第三方认证服务提供商，比如Auth0；

外部认证服务可以完全独立于我们自己的应用服务，并且不需要通过网络共享任何密钥信息。应用服务器不需要安装任何密钥，减少了密钥丢失或者被盗窃的风险。

此外，应用服务可以完全无状态，因为不需要在多个请求之间将token存储在内存。认证服务可以在生成token并返回给客户端后，马上丢弃它！同样，密码摘要也没有必要保存在应用数据库中，因此减少了被盗的风险和其它安全相关的bug。

此刻也许你心里想：我有一个内部应用，对此，JWT是一个好的方案吗？是的，在本文的最后一节里，我们将讨论JWT在这种典型场景下的使用情况。

• 目录

本文我们将讨论以下这些话题：

1. 什么是JWT？
2. JWT在线验证工具；
3. JWT的格式；
4. JWT的核心要素: Header, Payload, Signature；
5. Base64Url (vs Base64)；
6. 使用JWT进行会话管理: 主题和期限
7. HS256签名 – 它是如何工作的？
8. 数字签名；
9. 哈希函数和SHA-256；
10. RS256 JWT签名 – 谈谈公钥加密；
11. RS256 vs HS256 签名 – 哪种方式更好？
12. JWKS (JSON Web Key Set) 端点(Endpoints)；
13. 如何实现JWT签名的周期性键旋转(Periodic Key Rotation)；
14. JWT在企业应用中的使用；
15. 归纳和结论；

• JWT是什么?

JSON Web Token (or JWT)只是一个包含某种意义数据的JSON串。它最重要的特性就是，为了确认它是否有效，我们只需要看JWT本身的内容，而不需要借助于第三方服务或者在多个请求之间将其保存在内存中-这是因为它本身携带了信息验证码MAC(Message Authentication Code)。

一个JWT包含3个部分：头部Header，数据Payload，签名Signature。让我们逐个来了解一下，先从Payload开始吧。

• JWT Payload看起来是怎样的呢?

Payload只是一个普通的Javascript 对象。对于payload的内容，JWT是没有任何限制的，但必须注意的是，JWT是没有加密的。因此，任何放在token里面的信息，如果被截获了，对任何人别人是可读的。因此，我们不应该在Payload里面存放任何黑客可以利用的用户信息。

• JWT Header – 为什么是必须的?

Payload的内容在接收者端是通过签名(Signature)来校验的。不过存在多种类型的签名，因此，接收者需要知道使用的是哪种类型的签名。

这种关于token本身的元数据信息存放在另外的Javascript对象里面，并随着Payload一起发送给客户。这个独立的对象就是一个JSON对象，叫JWT Header，它也是普通的Javascript对象，在这里面我们可以看到签名类型信息，比如RS256。

• JWT signatures – 如何被使用来完成认证的?

JWT的最后一部分是签名，它也叫信息验证码MAC。签名只能由拥有Payload、Header和密钥的角色生成。

那签名是如何完成认证功能的呢，且看：

1. 用户向认证服务器提交用户名和密码，认证服务器也可以和应用服务器部署在一起，但往往是独立的居多；
2. 认证服务器校验用户名和密码组合，然后创建一个JWT token，token的Payload里面包含用户的身份信息，以及过期时间戳；
3. 认证服务器使用密钥对Header和Payload进行签名，然后发送给客户浏览器；
4. 浏览器获取到经过签名的JWT token，然后在之后的每个HTTP请求中附带着发送给应用服务器。经过签名的JWT就像一个临时的用户凭证，代替了用户名和密码组合，之后都是JWT token和应用服务器打交道了；
5. 应用服务器检查JWT签名，确认Payload确实是由密钥拥有者签过名的；
6. Payload身份信息代表了某个用户；
7. 只有认证服务器拥有私钥，并且认证服务器只把token发给提供了正确密码的用户；
8. 因此应用服务器可以认为这个token是由认证服务器颁发的也是安全的，因为该用户具有了正确的密码；
9. 应用服务器继续完成HTTP请求，并认为这些请求确实属于这个用户；

这样的话，黑客假扮合法用户的办法要么是盗到了用户名和密码组合，要么盗到了认证服务器上的签名私钥。

正如我们所见，签名的确是JWT的关键部分！

签名使得无状态的服务器只需要通过查看HTTP请求中的JWT token就能保证HTTP请求是来自某个用户，而不需要每次请求时都发送密码。

• JWT的目标是让服务器无状态?

实际上，JWT真正的好处是让认证服务器和校验JWT token的应用服务器可以完全分开，而让服务器无状态化只是它的一个副作用罢了。这意味着应用服务器只需要最简单的认证逻辑-校验JWT！我们可以将整个应用集群的登录/注册委托给一个单独的认证服务器。这也意味着应用服务器更简单更安全，因为更多的认证功能集中部署在认证服务器，可以被跨应用使用。

到此，我们从更高的层面了解了JWT是怎样完成