JWT

JWT

一、什么是JWT

根据维基百科的定义，JSON WEB Token（JWT，读作 [/dʒɒt/]），是一种基于JSON的、用于在网络上声明某种主张的令牌（token）。JWT通常由三部分组成: 头信息（header）, 消息体（payload）和签名（signature）。

1、头信息指定了该JWT使用的签名算法:

header = '{"alg":"HS256","typ":"JWT"}'

HS256 表示使用了 HMAC-SHA256 来生成签名。

2、消息体包含了JWT的意图：

payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间

3、未签名的令牌由base64url编码的头信息和消息体拼接而成（使用"."分隔），签名则通过私有的key计算而成：

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken) 

4、最后在未签名的令牌尾部拼接上base64url编码的签名（同样使用"."分隔）就是JWT了：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) 

结果：token看起来像如下这样eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

5、JWT常常被用作保护服务端的资源（resource），客户端通常将JWT通过HTTP的Authorization header发送给服务端，服务端使用自己保存的key计算、验证签名以判断该JWT是否可信：

Authorization: Bearer eyJhbGci*......*yu5CSpyHI

二、支持使用JWT方案的原因：

近年来RESTful API开始风靡，使用HTTP header来传递认证令牌似乎变得理所应当，而单页应用（SPA）、前后端分离架构似乎正在促成越来越多的WEB应用放弃历史悠久的cookie-session认证机制，转而使用JWT来管理用户session。

1、该方案更易于水平扩展

在cookie-session方案中，cookie内仅包含一个session标识符，而诸如用户信息、授权列表等都保存在服务端的session中。如果把session中的认证信息都保存在JWT中，在服务端就没有session存在的必要了。当服务端水平扩展的时候，就不用处理session复制（session replication）/ session黏连（sticky session）或是引入外部session存储了。

从这个角度来说，这个优点确实存在，但实际上外部session存储方案已经非常成熟了（比如Redis），在一些Framework的帮助下（比如spring-session和hazelcast），session复制也并没有想象中的麻烦。所以除非你的应用访问量非常非常非常（此处省略N个非常）大，使用cookie-session配合外部session存储完全够用了。

2、该方案可防护CSRF攻击

跨站请求伪造Cross-site request forgery（简称CSRF, 读作 [sea-surf]）是一种典型的利用cookie-session漏洞的攻击。

3、该方案更安全

由于JWT要求有一个秘钥，还有一个算法，生成的令牌看上去不可读，不少人误认为该令牌是被加密的。但实际上秘钥和算法是用来生成签名的，令牌本身不可读仅是因为base64url编码，可以直接解码，所以如果JWT中如果保存了敏感的信息，相对cookie-session将数据放在服务端来说，更不安全。