你真的了解JWT？JWT详解

引述：

相信不少朋友和我同样对于如今的登陆认证机制都有了必定的认识，而且已经在实施了.我目前接触到的安全认证是基于Spring Security Oauth2.0。

Oauth2.0的介绍网上有不少的文章，相信有的小伙伴已经看过了，甚至连源码都了解过了``。我今天说的是在Oauth之上的Token和JWT目前的主流认证模式中，都是用户输入用户名和密码进行登陆：

{ loginName: "xxx", password: "xxxxxxx" }

相似这样的机制，在我经历过的登陆验证中，咱们的处理办法是用户登陆在本地用户接口认证成功后调用Oauth认证服务器去进行二次验证并携带基本的client_id和grant_type等必要信息
这是Oauth的一种受权模式，这样的流程在成功以后咱们能够拿到一个基本的token（基于JWT编码的）

相似这样的返回机制：
{ access_token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsibWFydmVsLW9wZW4tYXBpIiwibWFydmVsLXZpZGVvLW1vbml0b3IiLCJtYXJ2ZWwtc3ViaXRlbS1zZXJ2ZXIiLCJtYXJ2ZWwtZ3VpZC1zZXJ2ZXIiLCJtYXJ2ZWwtaHItc2VydmVyIiwibWFydmVsLXByb2plY3Qtc2VydmVyIiwibWFydmVsLWF1dGgtc2VydmVyIiwibWFydmVsLXNjcmVlbi1zZXJ2ZXIiLCJtYXJ2ZWwtY29zdC1wYXJlbnQiLCJtYXJ2ZWwtc3VwZXJ2aXNpb24taW5zcGVjdGlvbiIsIm1hcnZlbC1taWRkbGUtc2VydmVyIiwibWFydmVsLXR1bm5lbC1wcm9ncmVzcyIsIm1hcnZlbC1lbmdpbmVlcmluZy1zZXJ2ZXIiLCJtYXJ2ZWwtbWVzc2FnZS1zZXJ2ZXIiXSwiZXhwIjoxNjI3NTc0MTA4LCJ1c2VyX25hbWUiOiJhZG1pbiIsImp0aSI6ImFjODg1ZDJiLWRhMTItNGI3Ni1hZjJjLWEzOWFhYjFlNWQ5ZCIsImNsaWVudF9pZCI6Im1pZGRsZSIsInNjb3BlIjpbInJlYWQiLCJ3cml0ZSJdfQ.aYhu0-J6XzNOzNRNdP5yJJqSXIsgZFABxyLZt2VBNjc" expires_in: 26780 jti: "ac885d2b-da12-4b76-af2c-a39aab1e5d9d" refresh_token: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsibWFydmVsLW9wZW4tYXBpIiwibWFydmVsLXZpZGVvLW1vbml0b3IiLCJtYXJ2ZWwtc3ViaXRlbS1zZXJ2ZXIiLCJtYXJ2ZWwtZ3VpZC1zZXJ2ZXIiLCJtYXJ2ZWwtaHItc2VydmVyIiwibWFydmVsLXByb2plY3Qtc2VydmVyIiwibWFydmVsLWF1dGgtc2VydmVyIiwibWFydmVsLXNjcmVlbi1zZXJ2ZXIiLCJtYXJ2ZWwtY29zdC1wYXJlbnQiLCJtYXJ2ZWwtc3VwZXJ2aXNpb24taW5zcGVjdGlvbiIsIm1hcnZlbC1taWRkbGUtc2VydmVyIiwibWFydmVsLXR1bm5lbC1wcm9ncmVzcyIsIm1hcnZlbC1lbmdpbmVlcmluZy1zZXJ2ZXIiLCJtYXJ2ZWwtbWVzc2FnZS1zZXJ2ZXIiXSwidXNlcl9uYW1lIjoiYWRtaW4iLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiYXRpIjoiYWM4ODVkMmItZGExMi00Yjc2LWFmMmMtYTM5YWFiMWU1ZDlkIiwiZXhwIjoxNjI5MTY2MTA4LCJqdGkiOiI1YzM1MjQ4OS03ZWEzLTRmMDgtOWExMy03Y2M2MDI2ODhjMDgiLCJjbGllbnRfaWQiOiJtaWRkbGUifQ.uGaynDuGOe8Mh4dOxKAjeUwT_sh1I81_E-UY0UtSGlY" scope: "read write" token_type: "bearer" }
这是一个标准的JWT返回格式的受权Token，
在拿到token后能够放到jwt.io中去解析他的token值
{ "aud": [ "marvel-open-api", "marvel-video-monitor", "marvel-subitem-server", "marvel-guid-server", "marvel-hr-server", "marvel-project-server", "marvel-auth-server", "marvel-screen-server", "marvel-cost-parent", "marvel-supervision-inspection", "marvel-middle-server", "marvel-tunnel-progress", "marvel-engineering-server", "marvel-message-server" ], "exp": 1627574108, "user_name": "admin", "jti": "ac885d2b-da12-4b76-af2c-a39aab1e5d9d", "client_id": "middle", "scope": [ "read", "write" ] }
这是咱们解析后获得的值

上面的aud是后端的微服务，每一个服务都有各自惟一标识，经过Oauth认证服务器颁发，有了该标识表明用户请求具体服务时通过网关转发后不会抛出401。

这是我目前的使用Jwt的主要流程，可是不少人估计和我同样彻底对于JWT很陌生，只知道他用来编码封装token的，对于他没有去了解，那么咱们一块儿来看看

JWT描述：

一、JWT简介：

JSON Web Token（JWT）是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519)，它定义了一种紧凑（Compact）且自包含（Self-contained）的方式，用于在各方之间以JSON对象安全传输信息。 这些信息能够经过数字签名进行验证和信任。 可使用秘密（使用HMAC算法）或使用RSA的公钥/私钥对对JWT进行签名。JWT的声明通常被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也能够增长一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。是目前最流行的跨域认证解决方案。
Compact（紧凑）： 因为它们尺寸较小，JWT能够经过URL，POST参数或HTTP标头内发送。 另外，尺寸越小意味着传输速度越快。
Self-contained（自包含）: 有效载荷（Playload）包含有关用户的全部必需信息，避免了屡次查询数据库。

一个签名的JWT被称为JWS (JSON Web签名)。 事实上，JWT自己并不存在——它必须是JWS或JWE (JSON Web加密)。 它就像一个抽象类——JWS和JWE是具体的实现。

感兴趣的深刻JWS和JWE的能够阅读此文章：https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3

二、JWT应用场景：

Authentication（鉴权）： 这是使用JWT最多见的状况。 一旦用户登陆，每一个后续请求都将包含JWT，容许用户访问该令牌容许的路由，服务和资源。 单点登陆是当今普遍使用JWT的一项功能，由于它的开销很小，而且可以轻松地跨不一样域使用。
分布式站点的单点登陆（SSO）
Information Exchange（信息交换）： JSON Web Tokens是在各方之间安全传输信息的好方式。 由于JWT能够签名：例如使用公钥/私钥对，因此能够肯定发件人是他们自称的人。 此外，因为使用标头和有效载荷计算签名，所以您还能够验证内容是否未被篡改。

三、JWT组成：

jwt有3个组成部分，每部分经过点号来分割 header.payload.signature
头部（header) 是一个 JSON 对象，描述 JWT 的元数据，一般是下面的样子
载荷（payload) 是一个 JSON 对象，用来存放实际须要传递的数据
签证（signature) 对header和payload使用密钥进行签名，防止数据篡改。

① 头部header

Jwt的头部是一个JSON,而后使用Base64URL编码，承载两部分信息：
声明类型typ，表示这个令牌（token）的类型（type），JWT令牌统一写为JWT
声明加密的算法alg，一般直接使用HMACSHA256，就是HS256了，也可使用RSA,支持不少算法(HS25六、HS38四、HS5十二、RS25六、RS38四、RS5十二、ES25六、ES38四、ES5十二、PS25六、PS384)
var header = Base64URL({ "alg": "HS256", "typ": "JWT"})
Base64URL：Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本相似，但有一些小的不一样。JWT 做为一个令牌（token），有些场合可能会放到 URL（好比 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，因此要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

② 载荷payload

payload也是一个JSON字符串，是承载消息具体内容的地方，也须要使用Base64URL编码，payload中能够包含预约义的7个可用，它们不是强制性的，但推荐使用，也能够添加任意自定义的key
iss(issuer): jwt签发者
sub(subject): jwt所面向的用户
aud(audience): 接收jwt的一方, 受众
exp(expiration time): jwt的过时时间，这个过时时间必需要大于签发时间
nbf(Not Before): 生效时间，定义在什么时间以前.
iat(Issued At): jwt的签发时间
jti(JWT ID): jwt的惟一身份标识，主要用来做为一次性token,从而回避重放攻击。
// 该token签发给1234567890，姓名为John Doe(自定义的字段)，签发时间为1516239022
var payload = Base64URL( {"sub": "1234567890", "name": "John Doe", "iat": 1516239022})

注意，JWT中payload是不加密的，只是Base64URL编码一下，任何人拿到均可以进行解码，因此不要把敏感信息放到里面。

③ signature

Signature 部分是对前两部分的签名，防止数据篡改。

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，因此，它就是你服务端的私钥，在任何场景都不该该流露出去。一旦客户端得知这个secret, 那就意味着客户端是能够自我签发jwt了。

四、JWT特色：

由于json的通用性，因此JWT是能够进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等不少语言均可以使用。
由于有了payload部分，因此JWT能够在自身存储一些其余业务逻辑所必要的非敏感信息。
它不须要在服务端保存会话信息, 因此它易于应用的扩展
JWT 的几个特色

（1）JWT 默认是不加密，但也是能够加密的。生成原始 Token 之后，能够用密钥再加密一次。

（2）JWT 不加密的状况下，不能将敏感数据(如密码)写入 JWT，除非对payload进行加密。保护好secret私钥，该私钥很是重要。

（3）JWT 不只能够用于认证，也能够用于交换信息。有效使用 JWT，能够下降服务器查询数据库的次数。

（4）JWT 的最大缺点是，因为服务器不保存 session 状态，所以没法在使用过程当中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期以前就会始终有效，除非服务器部署额外的逻辑。

（5）JWT 自己包含了认证信息，一旦泄露，任何人均可以得到该令牌的全部权限。为了减小盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

（6）为了减小盗用，JWT 不该该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

五、JWT优势：

体积小，于是传输速度更快
多样化的传输方式，能够经过URL传输、POST传输、请求头Header传输（经常使用）
简单方便，服务端拿到jwt后无需再次查询数据库校验token可用性，也无需进行redis缓存校验
在分布式系统中，很好地解决了单点登陆问题
很方便的解决了跨域受权问题，由于跨域没法共享cookie

六、JWT缺点：

由于JWT是无状态的，所以服务端没法控制已经生成的Token失效，是不可控的，这一点对因而否使用jwt是须要重点考量的
获取到jwt也就拥有了登陆权限，所以jwt是不可泄露的，网站最好使用https，防止中间攻击偷取jwt
在退出登陆 / 修改密码时怎样实现JWT Token失效https://segmentfault.com/q/1010000010043871

七、JWT安全性：

JWT被确实存在被窃取的问题，可是若是能获得别人的token，其实也就至关于能窃取别人的密码，这其实已经不是JWT安全性的问题。网络是存在多种不安全性的，对于传统的session登陆的方式，若是别人能窃取登陆后的sessionID，也就能模拟登陆状态，这和JWT是相似的。为了安全，https加密很是有必要，对于JWT有效时间最好设置短一点。

八、JWT常见问题：

① JWT 安全吗?

Base64编码方式是可逆的，也就是透过编码后发放的Token内容是能够被解析的。通常而言，不建议在有效载荷内放敏感信息，好比使用者的密码。

② JWT Payload 內容能够被伪造吗？

JWT其中的一个组成内容为Signature，能够防止经过Base64可逆方法回推有效载荷内容并将其修改。由于Signature是经由Header跟Payload一块儿Base64组成的。

③ 若是个人 Cookie 被窃取了，那不就表示第三方能够作 CSRF 攻击?

是的，Cookie丢失，就表示身份就能够被伪造。故官方建议的使用方式是存放在LocalStorage中，并放在请求头中发送。

④ 空间及长度问题？

JWT Token一般长度不会过小，特别是Stateless JWT Token，把全部的数据都编在Token里，很快的就会超过Cookie的大小（4K）或者是URL长度限制。

⑤ Token失效问题？

无状态JWT令牌（Stateless JWT Token）发放出去以后，不能经过服务器端让令牌失效，必须等到过时时间过才会失去效用。

假设在这之间Token被拦截，或者有权限管理身份的差别形成受权Scope修改，都不能阻止发出去的Token失效并要求使用者从新请求新的Token。

九、JWT使用建议：

Payload中的exp时效不要设定太长。
开启Only Http预防XSS攻击。
若是担忧重播攻击（replay attacks ）能够增长jti（JWT ID），exp（有效时间） Claim。
在你的应用程序应用层中增长黑名单机制，必要的时候能够进行Block作阻挡（这是针对掉令牌被第三方使用窃取的手动防护）。

十、JWT与OAuth的区别

OAuth2是一种受权框架 ，JWT是一种认证协议 -不管使用哪一种方式切记用HTTPS来保证数据的安全性 -OAuth2用在使用第三方帐号登陆的状况(好比使用weibo, qq, github登陆某个app)，而JWT是用在先后端分离, 须要简单的对后台API进行保护时使用。

总结

其实JWT并不在加密保护数据，而是为了认证来源。
JWT不保证数据不泄露，由于JWT的设计目的就不是数据加密和保护。
Angular 的文档中也对于JWT有很是深刻的讲解，感兴趣的同窗能够去深刻了解，地址在下方。

本文引用地址：
JWT文档：https://jwt.io/introduction/
JWT描述：http://www.javashuo.com/article/p-mxljvern-gy.html
Angular文档对于JWT了解：https://blog.angular-university.io/angular-jwt/
一文说清楚JWT，JWS，JWE：https://www.jianshu.com/p/50ade6f2e4fd
知乎一文说清楚JWT：https://zhuanlan.zhihu.com/p/86937325
JWS和JWE深刻：
https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3，
https://darutk.medium.com/understanding-id-token-5f83f50fa02e