凭证

在前面介绍 OAuth2 的内容中，每一种授权模式的最终目标都是拿到访问令牌，但从未涉及过拿回来的令牌应该长什么样子。反而还挖了一些坑没有填（为何说 OAuth2 的一个主要缺陷是令牌难以主动失效）。这节讨论的主角是令牌，同时，还会讨论如果不使用 OAuth2，如何以最传统的方式完成认证、授权。

“如何承载认证授权信息”这个问题的不同看法，代表了软件架构对待共享状态信息的两种不同思路：状态应该维护在服务端，抑或是在客户端之中？在分布式系统崛起以前，这个问题原本已是有了较为统一的结论的，以 HTTP 协议的 Cookie-Session 机制为代表的服务端状态存储在三十年来都是主流的解决方案。不过，到了最近十年，由于分布式系统中共享数据必然会受到 CAP 不兼容原理的打击限制，迫使人们重新去审视之前已基本放弃掉的客户端状态存储，这就让原本通常只在多方系统中采用的 JWT 令牌方案，在分布式系统中也有了另一块用武之地。本节的话题，也就围绕着 Cookie-Session 和 JWT 之间的相同与不同而展开。

大家知道 HTTP 协议是一种无状态的传输协议，无状态是指协议对事务处理没有上下文的记忆能力，每一个请求都是完全独立的，但是我们中肯定有许多人并没有意识到 HTTP 协议无状态的重要性。假如你做了一个简单的网页，其中包含了 1 个 HTML、2 个 Script 脚本、3 个 CSS、还有 10 张图片，这个网页成功展示在用户屏幕前，需要完成 16 次与服务端的交互来获取上述资源，由于网络传输各种等因素的影响，服务器发送的顺序与客户端请求的先后并没有必然的联系，按照可能出现的响应顺序，理论上最多会有 P(16,16) = 20,922,789,888,000 种可能性。试想一下，如果 HTTP 协议不是设计成无状态的，这 16 次请求每一个都有依赖关联，先调用哪一个、先返回哪一个，都会对结果产生影响的话，那协调工作会有多么复杂。

可是，HTTP 协议的无状态特性又有悖于我们最常见的网络应用场景，典型就是认证授权，系统总得要获知用户身份才能提供合适的服务，因此，我们也希望 HTTP 能有一种手段，让服务器至少有办法能够区分出发送请求的用户是谁。为了实现这个目的，RFC 6265规范定义了 HTTP 的状态管理机制，在 HTTP 协议中增加了 Set-Cookie 指令，该指令的含义是以键值对的方式向客户端发送一组信息，此信息将在此后一段时间内的每次 HTTP 请求中，以名为 Cookie 的 Header 附带着重新发回给服务端，以便服务端区分来自不同客户端的请求。一个典型的 Set-Cookie 指令如下所示：

Set-Cookie: id=icyfenix; Expires=Wed, 21 Feb 2020 07:28:00 GMT; Secure; HttpOnly

收到该指令以后，客户端再对同一个域的请求中就会自动附带有键值对信息id=icyfenix，譬如以下代码所示：

GET /index.html HTTP/2.0
Host: icyfenix.cn
Cookie: id=icyfenix

根据每次请求传到服务端的 Cookie，服务器就能分辨出请求来自于哪一个用户。由于 Cookie 是放在请求头上的，属于额外的传输负担，不应该携带过多的内容，而且放在 Cookie 中传输也并不安全，容易被中间人窃取或被篡改，所以通常是不会像例子中设置id=icyfenix这样的明文信息。一般来说，系统会把状态信息保存在服务端，在 Cookie 里只传输的是一个无字面意义的、不重复的字符串，习惯上以sessionid或者jsessionid为名，服务器拿这个字符串为 Key，在内存中开辟一块空间，以 Key/Entity 的结构存储每一个在线用户的上下文状态，再辅以一些超时自动清理之类的管理措施。这种服务端的状态管理机制就是今天大家非常熟悉的 Session，Cookie-Session 也即最传统但今天依然广泛应用于大量系统中的，由服务端与客户端联动来完成的状态管理机制。

Cookie-Session 方案在本章的主题“安全性”上其实是有一定先天优势的：状态信息都存储于服务器，只要依靠客户端的同源策略和 HTTPS 的传输层安全，保证 Cookie 中的键值不被窃取而出现被冒认身份的情况，就能完全规避掉上下文信息在传输过程中被泄漏和篡改的风险。Cookie-Session 方案的另一大优点是服务端有主动的状态管理能力，可根据自己的意愿随时修改、清除任意上下文信息，譬如很轻易就能实现强制某用户下线的这样功能。

Session-Cookie 在单节点的单体服务环境中是最合适的方案，但当需要水平扩展服务能力，要部署集群时就开始面临麻烦了，由于 Session 存储在服务器的内存中，当服务器水平拓展成多节点时，设计者必须在以下三种方案中选择其一：

通过前面章节的内容，我们已经知道只要在分布式系统中共享信息，CAP 就不可兼得，所以分布式环境中的状态管理一定会受到 CAP 的局限，无论怎样都不可能完美。但如果只是解决分布式下的认证授权问题，并顺带解决少量状态的问题，就不一定只能依靠共享信息去实现。这句话的言外之意是提醒读者，接下来的 JWT 令牌与 Cookie-Session 并不是完全对等的解决方案，它只用来处理认证授权问题，充其量能携带少量非敏感的信息，只是 Cookie-Session 在认证授权问题上的替代品，而不能说 JWT 要比 Cookie-Session 更加先进，更不可能全面取代 Cookie-Session 机制。

Cookie-Session 机制在分布式环境下会遇到 CAP 不可兼得的问题，而在多方系统中，就更不可能谈什么 Session 层面的数据共享了，哪怕服务端之间能共享数据，客户端的 Cookie 也没法跨域。所以我们不得不重新捡起最初被抛弃的思路，当服务器存在多个，客户端只有一个时，把状态信息存储在客户端，每次随着请求发回服务器去。笔者才说过这样做的缺点是无法携带大量信息，而且有泄漏和篡改的安全风险。信息量受限的问题并没有太好的解决办法，但是要确保信息不被中间人篡改则还是可以实现的，JWT 便是这个问题的标准答案。

JWT（JSON Web Token）定义于RFC 7519标准之中，是目前广泛使用的一种令牌格式，尤其经常与 OAuth2 配合应用于分布式的、涉及多方的应用系统中。介绍 JWT 的具体构成之前，我们先来直观地看一下它是什么样子的，如图 5-13 所示。

以上截图来自 JWT 官网（https://jwt.io），数据则是笔者随意编的。右边的 JSON 结构是 JWT 令牌中携带的信息，左边的字符串呈现了 JWT 令牌的本体。它最常见的使用方式是附在名为 Authorization 的 Header 发送给服务端，前缀在RFC 6750中被规定为 Bearer。如果你没有忘记“ 认证 ”与“ OAuth 2 ”的内容，那看到 Authorization 这个 Header 与 Bearer 这个前缀时，便应意识到它是 HTTP 认证框架中的 OAuth 2 认证方案。如下代码展示了一次采用 JWT 令牌的 HTTP 实际请求：

GET /restful/products/1 HTTP/1.1
Host: icyfenix.cn
Connection: keep-alive
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX25hbWUiOiJpY3lmZW5peCIsInNjb3BlIjpbIkFMTCJdLCJleHAiOjE1ODQ5NDg5NDcsImF1dGhvcml0aWVzIjpbIlJPTEVfVVNFUiIsIlJPTEVfQURNSU4iXSwianRpIjoiOWQ3NzU4NmEtM2Y0Zi00Y2JiLTk5MjQtZmUyZjc3ZGZhMzNkIiwiY2xpZW50X2lkIjoiYm9va3N0b3JlX2Zyb250ZW5kIiwidXNlcm5hbWUiOiJpY3lmZW5peCJ9.539WMzbjv63wBtx4ytYYw_Fo1ECG_9vsgAn8bheflL8

图 5-13 中右边的状态信息是对令牌使用 Base64URL 转码后得到的明文，请特别注意是明文，JWT 只解决防篡改的问题，并不解决防泄漏的问题，因此令牌默认是不加密的。尽管你自己要加密也并不难做到，接收时自行解密即可，但这样做其实没有太大意义，原因笔者将在下一节“ 保密 ”中去解释。

从明文中可以看到 JWT 令牌是以 JSON 结构（毕竟名字就叫 JSON Web Token）存储的，结构总体上可划分为三个部分，每个部分间用点号.分隔开。

第一部分是令牌头 （Header），内容如下所示：

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

它描述了令牌的类型（统一为 typ:JWT）以及令牌签名的算法，示例中 HS256 为 HMAC SHA256 算法的缩写，其他各种系统支持的签名算法可以参考https://jwt.io/网站所列。

令牌的第二部分是负载 （Payload），这是令牌真正需要向服务端传递的信息。针对认证问题，负载至少应该包含能够告知服务端“这个用户是谁”的信息，针对授权问题，令牌至少应该包含能够告知服务端“这个用户拥有什么角色/权限”的信息。JWT 的负载部分是可以完全自定义的，根据具体要解决的问题不同，设计自己所需要的信息，只是总容量不能太大，毕竟要受到 HTTP Header 大小的限制。一个 JWT 负载的例子如下所示：

{
  "username": "icyfenix",
  "authorities": [
    "ROLE_USER",
    "ROLE_ADMIN"
  ],
  "scope": [
    "ALL"
  ],
  "exp": 1584948947,
  "jti": "9d77586a-3f4f-4cbb-9924-fe2f77dfa33d",
  "client_id": "bookstore_frontend"
}

而 JWT 在 RFC 7519 中推荐（非强制约束）了七项声明名称（Claim Name），如有需要用到这些内容，建议字段名与官方的保持一致：

此外在 RFC 8225、RFC 8417、RFC 8485 等规范文档，以及 OpenID 等协议中，都定义有约定好公有含义的名称，内容比较多，笔者就不贴出来了，可以参考IANA JSON Web Token Registry。

令牌的第三部分是签名 （Signature），签名的意思是：使用在对象头中公开的特定签名算法，通过特定的密钥（Secret，由服务器进行保密，不能公开）对前面两部分内容进行加密计算，以例子里使用的 JWT 默认的 HMAC SHA256 算法为例，将通过以下公式产生签名值：

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

签名的意义在于确保负载中的信息是可信的、没有被篡改的，也没有在传输过程中丢失任何信息。因为被签名的内容哪怕发生了一个字节的变动，也会导致整个签名发生显著变化。此外，由于签名这件事情只能由认证授权服务器完成（只有它知道 Secret），任何人都无法在篡改后重新计算出合法的签名值，所以服务端才能够完全信任客户端传上来的 JWT 中的负载信息。

JWT 默认的签名算法 HMAC SHA256 是一种带密钥的哈希摘要算法，加密与验证过程均只能由中心化的授权服务来提供，所以这种方式一般只适合于授权服务与应用服务处于同一个进程中的单体应用。在多方系统或者授权服务与资源服务分离的分布式应用中，通常会采用非对称加密算法来进行签名，这时候除了授权服务端持有的可以用于签名的私钥外，还会对其他服务器公开一个公钥，公开方式一般遵循JSON Web Key 规范。公钥不能用来签名，但是能被其他服务用于验证签名是否由私钥所签发的。这样其他服务器也能不依赖授权服务器、无须远程通信即可独立判断 JWT 令牌中的信息的真伪。

在 Fenix's Bookstore 的单体服务版本中，采用了默认的 HMAC SHA256 算法来加密签名，而 Istio 服务网格版本里，终端用户认证会由服务网格的基础设施参来完成，此时就改用了非对称加密的 RSA SHA256 算法来进行签名，希望深入了解凭证安全的读者，不妨对比一下这两部分的代码。更多关于哈希摘要、对称和非对称加密的讨论，将会在“ 传输 ”一节中继续进行。

JWT 令牌是多方系统中一种优秀的凭证载体，它不需要任何一个服务节点保留任何一点状态信息，就能够保障认证服务与用户之间的承诺是双方当时真实意图的体现，是准确、完整、不可篡改、且不可抵赖的。同时，由于 JWT 本身可以携带少量信息，这十分有利于 RESTFul API 的设计，能够较容易地做成无状态服务，在做水平扩展时就不需要像前面 Cookie-Session 方案那样考虑如何部署的问题。现实中也确实有一些项目直接采用 JWT 来承载上下文来实现完全无状态的服务端，这能获得任意加入或移除服务节点的巨大便利，天然具有完美的水平扩缩能力。譬如，在调试 Fenix's Bookstore 的代码时，你随时都可以重启服务，重启后，客户端仍然能毫无感知地继续操作流程；而对于有状态的系统，就必须通过重新登录、进行前置业务操作来为服务端重建状态。尽管大型系统中只使用 JWT 来维护上下文状态，服务端完全不持有状态是不太现实的，不过将热点的服务单独抽离出来做成无状态，仍是一种有效提升系统吞吐能力的架构技巧。但是，JWT 也并非没有缺点的完美方案，它存在着以下几个经常被提及的缺点：