唐玄奘把 「JWT 令牌」玩到了极致
唐玄奘把 「JWT 令牌」玩到了极致
你好，我是悟空。
西游记的故事想必大家在暑假看过很多遍了，为了取得真经，唐玄奘历经苦难，终于达成。
在途经各国的时候，唐玄奘都会拿出一个通关文牒交给当地的国王进行盖章，方能通过。
本篇目录如下：
通关文牒
通关文牒就是唐朝官方发的一个凭证，证明持有人来自东土大唐，一般是使臣持有。
有了这个凭证后，到其他国家，比如女儿国国王看到这个凭证后，就会放行。
下面来一张西游记中通关文牒的生命周期图。
长安是一个颁发凭证（通关文牒）的微服务节点，乌鸡国、女儿国和大雷音寺等都是集群中的一个微服务节点，唐玄奘拿着凭证访问各国。
那为什么别的国家认可这个凭证呢？
那是因为当时的唐朝非常强大，有很多国家都要向唐朝朝贡，与唐朝交好有很多好处的~
朝贡也有篇故事哦~唐太宗把微服务的“心跳机制”玩到了极致！
唐太宗在通关文牒上写道：“倘到西邦诸国，不灭善缘，照牒放行，须至牒者。”
意思就是说唐玄奘法师是我们唐朝的使臣，如果途经诸侯国，希望大家放行。
贞观之治时期的唐朝是在经济文化上都无比繁盛，国力强盛，周边国家都希望和唐朝建立友好关系，看到是唐朝使臣来了，好生招待下，然后盖章放行，给唐朝留个好印象。
在安全架构中，凭证 出现得太频繁了，比如我们在网关这一层加的校验令牌，其实就是校验凭证。
凭证是什么
凭证（Credentials）的出现就是系统保证它与用户之间的承诺是双方当时真实意图的体现，是准确、完整且不可抵赖的。
那唐太宗给唐玄奘的通关文牒就是一个凭证，上面盖着唐朝的官印、唐太宗的亲笔，这充分体现了持有者是拥有一个可信的令牌的，而且这个通关文牒上的官印是不可篡改的，如果改了，其他国家就不认了。
上面这种模式其实对应的是一种普通的认证授权模式，而大名鼎鼎的 OAuth 2.0 认证授权模式虽然有五种模式，但他们殊途同归，最后的目的都是生成一个凭证给到客户端，让客户端持有这个凭证来访问资源。关于 OAuth2.0 本篇不做展开。
关于凭证的存储方案，业界的安全架构中有两种方案：
- Cookie-Session 模式
- JWT 方案
Cookie-Session 模式
流程图如下：
用户登录认证通过后，后端会存放该客户端的身份信息，也就是存放到 session 中，session 可以用来区分不同，然后返回一个 sessionId 给到客户端。
客户端将 sessionId 缓存在客户端。当客户端下次发送 HTTP 请求时，在 header 的 cookie 字段附带着 sessionId 发送给后端服务器。
后端服务器拿到 header 中的 sessionId，然后根据 sessionId 找到 session，如果 session 存在，则从 session 中解析出用户的身份信息，然后执行业务逻辑。
我们都知道 HTTP 协议是一种无状态的传输协议，无状态表示对一个事务的处理没有上下文的记忆能力，每一个 HTTP 请求都是完全独立的。但是 Cookie-Seesion 模式却和 HTTP 无状态特性相悖，因为客户端访问资源时，是携带第一次拿到的 sessionId 的，让服务端能够顺利区分出发送请求的用户是谁。
服务端对 session 的管理，就是一种状态管理机制，该机制存储了每个在线用户的上下文状态，再加上一些超时自动清理的管理措施。Cookie-Session 也是最传统但今天依旧应用到大量系统中，由服务端与客户端联动来完成的状态管理机制。
放到西游记中，如果用这种 Cookie-Session 模式是怎么样的呢？
我们把唐朝和周边国家想想成一个
分布式集群，所有国家都需要将唐玄奘这个使者信息都保存一份（分布式存储），当唐玄奘路过某个国家时，需要查询本地存储中是否有唐玄奘，如果有，则认为唐玄奘是合法的使者，可以放行。
但是这种方式就会需要每个国家都同步保存，同步的成本是非常高昂的，而且会有同步延迟的存在。
Cookie-Session 模式的优势
状态信息都存储于服务器，只要依靠客户端的同源策略和 HTTPS 的传输层安全，保证 Cookie 中的键值不被窃取而出现被冒认身份的情况，就能完全规避掉上下文信息在传输过程中被泄漏和篡改的风险。Cookie-Session 方案的另一大优点是服务端有主动的状态管理能力，可根据自己的意愿随时修改、清除任意上下文信息，譬如很轻易就能实现强制某用户下线的这样功能。（来自凤凰架构）
Cookie-Session 模式的劣势
在单节点的单体服务中再适合不过，但是如果需要水平扩展要部署集群就很麻烦。
如果让 session 分配到不同的的节点上，不重复地保存着一部分用户的状态，用户的请求固定分配到对应的节点上，如果某个节点崩溃了，则里面的用户状态就会完全丢失。如果让 session 复制到所有节点上，那么同步的成本又会很高。
而为了解决分布式下的认证授权问题，并顺带解决少量状态的问题，就有了 JWT 令牌方案，但是 JWT 令牌和 Cookie-Session 并不是完全对等的解决方案，JWT 只能处理认证授权问题，且不能说 JWT 比 Cookie-Session 更加先进，也不可能全面取代 Cookie-Seesion 机制。
JWT 方案
我们上面说到 Cookie-Session 机制在分布式环境下会遇到一致性和同步成本的问题，而且如果在多方系统中，则更不能将 Session 共享存放在多方系统的服务端中，即使服务端之间能共享数据，Cookie 也没有办法跨域。
转换思路，服务端不保存任何状态信息，由客户端来存储，每次发送请求时携带这个状态信息发给后端服务。原理图如下所示：
但是这种方式无法携带大量信息，而且有泄漏和篡改的安全风险。信息量大小受限没有比较好的解决方案，但是确保信息不被中间人篡改则可以借助 JWT 方案。
JWT（JSON WEB TOKEN）是一种令牌格式，经常与 OAuth2.0 配合应用于分布式、多方的应用系统中。
我们先来看下 JWT 的格式长什么样：
以上截图来自 JWT 官网（https://jwt.io），数据则是悟空随意编的。
左边的字符串就是 JWT 令牌，JWT 令牌是服务端生成的，客户端会拿着这个 JWT 令牌在每次发送请求时放到 HTTP header 中。
而右边是 JWT 经过 Base64 解码后展示的明文内容，而这段明文内容的最下方，又有一个签名内容，可以防止内容篡改，但是不能解决泄漏的问题。
JWT 格式
JWT 令牌是以 JSON 结构存储，用点号分割为三个部分。
第一部分是令牌头（Header），内容如下所示：
{
"alg": "HS256",
"typ": "JWT"
}
它描述了令牌的类型（统一为 typ:JWT）以及令牌签名的算法，示例中 HS256 为 HMAC SHA256 算法的缩写，其他各种系统支持的签名算法可以参考https://jwt.io/网站所列。
令牌的第二部分是负载（Payload），这是令牌真正需要向服务端传递的信息。但是服务端不会直接用这个负载，而是通过加密传过来的 Header 和 Payload 后再比对签名是否一致来判断负载是否被篡改，如果没有被篡改，才能用 Payload 中的内容。因为负载只是做了 base64 编码，并不是加密，所以是不安全的，千万别把敏感信息比如密码放到负载里面。
{
"sub": "passjava",
"name": "悟空聊架构",
"iat": 1516239022
}
令牌的第三部分是签名（Signature），使用在对象头中公开的特定签名算法，通过特定的密钥（Secret，由服务器进行保密，不能公开）对前面两部分内容进行加密计算，以例子里使用的 JWT 默认的 HMAC SHA256 算法为例，将通过以下公式产生签名值：
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)
签名的意义：确保负载中的信息是可信的、没有被篡改的，也没有在传输过程中丢失任何信息。因为被签名的内容哪怕发生了一个字节的变动，也会导致整个签名发生显著变化。此外，由于签名这件事情只能由认证授权服务器完成（只有它知道 Secret），任何人都无法在篡改后重新计算出合法的签名值，所以服务端才能够完全信任客户端传上来的 JWT 中的负载信息。
JWT 的优势
- 无状态：不需要服务端保存 JWT 令牌，也就是说不需要服务节点保留任何一点状态信息，就能在后续的请求中完成认证功能。
- 天然的扩容便利：服务做水平扩容不用考虑 JWT 令牌，而 Cookie-Session 是需要考虑扩容后服务节点如何存储 Session 的。
- 不依赖 Cookie：JWT 可以存放在浏览器的 LocalStorage，不一定非要存储在 Cookie 中。
JWT 的劣势
令牌难以主动失效：JWT 令牌签发后，理论上和认证的服务器就没有什么关系了，到期之前始终有效。除非服务器加些特殊的逻辑处理来缓存 JWT，并来管理 JWT 的生命周期，但是这种方式又会退化成有状态服务。而这种要求有状态的需求又很常见：譬如用户退出后，需要重新输入用户名和密码才能登录；或者用户只允许在一台设备登录，登录到另外一台设备，要求强行退出。但是这种有状态的模式，降低了 JWT 本身的价值。
更容易遭受重放攻击：Cookie-Session 也有重放攻击的问题，也就是客户端可以拿着这个 cookie 不断发送大量请求，对系统性能造成影响。但是因为 Session 在服务端也有一份，服务端可以控制 session 的生命周期，应对重放攻击更加主动一些。但是 JWT 的重放攻击对于服务端来说就很被动，比如通过客户端的验证码、服务端限流或者缩短令牌有效期，应用起来都会麻烦些。
存在泄漏的风险：客户端存储，很有可能泄漏出去，被其他人重复利用。
信息大小有限：HTTP 协议并没有强制约束 Header 的最大长度，但是服务器、浏览器会做限制。而且如果令牌很大还会消耗传输带宽。
真假美猴王
西游记中还有一个章节，假的美猴王带着通关文牒和其他行李跑到了花果山，还想自行取经，这不就是盗用 JWT 令牌了吗？
如何使用 JWT
Java 有现成的工具类可以使用，而且校验 JWT 的工作可以统一交给网关来做，这个就是下一篇要重点讲解的实战内容了。
总结
唐玄奘就好比客户端，通关文牒就好比 JWT 令牌，经过的每个国家就好比集群中的微服务。
唐玄奘借助 JWT 令牌的认证授权模式，一路通关，最终取得真经，是不是很酷呀~
下一篇：手摸手实战 Spring Cloud Gateway + JWT 认证功能
参考资料：
《凤凰架构》
《OAuth2.0 实战》