jwt的本质与用途
JWT本质
相信大家都接触过一类开放平台，平台给开发者提供开发者帐号与密码。
开发者调用API时明文传递帐号，并用密码对请求参数做一个MD5之类的签名，服务端会再次计算签名并与你提交的签名比对，从而确认身份合法。
JWT本质上就是这样一个东西，只不过jwt是一个规范，规范的好处就是会有很多开源项目。
JWT的签名算法也不局限于MD5，比如可以是基于RSA的签名（私钥签名，公钥验证）。
发散一下
先假设现在jwt的使用场景就是上面的开放平台，然后发散一下。
防止jwt泄露
客户端调用API携带jwt，必须保障jwt不会被网络窃取，所以要使用https保护。
防止重放
假设jwt在不知情的情况下泄露，又该如何防范？
一般可以在jwt明文中引入当前时间戳，并一起参与签名。服务端需要校验时间戳在N分钟内，从而及时阻止重放攻击。
开放平台一般还要求将请求参数一起参与签名，这会进一步提升安全性，即攻击者只能重放某一个资源。
逆向思维
前面jwt是客户端生成的，客户端/服务端都知晓帐号密码，从而实现服务端验证，一般用在API场景。
逆向思维就是服务端生成jwt，保存在客户端使用，一般用在web。
我们比较熟悉基于cookie+session的方案，服务端保存登录会话信息，客户端保存一个会话标识。然而Jwt是客户端明文存储，服务端无存储，所以不能够保存敏感的会话信息。
cookie+session方案下，服务端可以实现会话立即注销，而jwt只保存在客户端，所以服务端签发jwt时，一般会在明文中记录当前时间戳并签名，实现jwt的有效期控制。
逆向场景下的jwt比较难以利用，但是也存在一些场景。
一个常见场景就是找回密码，服务器会发送一个链接到你的邮箱，点击链接就可以直接修改密码。
服务端是如何确认访问链接用户的合法性呢？通常做法会在链接里放一个用户标识，一个时间戳，以及一个签名，当点击链接时服务端校验签名确认合法性，这些信息可以统一保存在jwt中。
找回密码链接一般访问一次即会失效，这种情况下服务端会涉及到存储，即生成一次性的标识取代用户标识，并在存储中记录访问状态，确保访问一次即失效。
jwt在这里就是提供一种规范的标识传递和签名方法，它本身并不会给上述逆向业务场景带来完全的安全性，而是需要业务根据实际情况决定签名哪些信息，是否服务端存储。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
