生成token的加密规则

因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用

​存储可以按照userId—token的方式存储在数据库中（当然也可以按你喜欢添加其他字段标明其他信息，比如说mac地址啦，是手机还是电脑啦，设备型号啦，巴拉巴拉巴拉····），白名单的话直接存储有效的token，在需要token无效的逻辑中删除指定token即可（比如刷新token的时候把旧的无效的但未过期的删掉）。而如果是黑名单的话就需要你定期去删除其中已经过期的token了。

对于频繁更换的Token，如何处理旧的未过期的而又无效的refreshToken，以下提供了几个思路：

​token即为令牌，是服务器生成的一串字符串，作为客户端向服务器进行请求的“通行证”。在客户端进行初次登陆后由服务器返回，之后的每次请求只需要携带token进行请求即可，而无需携带密码等敏感信息

显然，这种方式对于服务器方面的安全而言并没有什么卵用，但它能通过移除存在的token来阻止攻击者（比如，攻击者必须在用户下线之前窃取到token）

token加密与解密算法

​顾名思义，就是在登陆操作之后由服务端返回两个token：accessToken和refreshToken，在之后的验证登录态的操作中使用这两个token进行验证，其中accessToken的过期时间相当短，refreshToken的过期时间

便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。它不需要在服务端保存会话信息,所以它易于应用的扩展

refreshToekn的存在，保证了用户（即使是非活跃用户）无需在短时间内进行反复的登陆操作来保证登录态的有效性，同时也保证了活跃用户的登录态可以一直存续而不需要进行重新登录，其反复刷新也防止某些不怀好意的人获取refreshToken后对用户帐号进行动手动脚的操作（拒绝NTR.jpg）

通俗的来讲就是第三部分是个大杂烩，把上述3个部分丢到加密算法这个大锅里煮（加密），煮出来的菜就是第三部分

由于token的组成关系，前2部分只用了base64这种可以随意解密的东西加密的，而第三部分作为凭证留在了客户端，因此，

安全工具token

客户端第一次发出登录请求时，用户密码以明文的方式传输，一旦被截获，后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

引入token后，上述问题便可得到解决。服务器将token和其它的一些变量，利用散列加密算法得到签名后，连同sessionId一并发送给服务器；服务器取出保存于服务器端的token,利用相同的法则生成校验签名，如果客户端签名与服务器的校验签名一致，就认为请求来自登录的客户端。

服务器利用保留的私钥对密文进行解密，得到真正的密码。经过判断，确定用户可以登录后，生成sessionId和token，同时利用客户端发送的公钥，对token进行加密。最后将sessionId和加密后的token返还给客户端。

标签： #token #加密 #解密