基于双Token实现登录设计思考的一些问题

做之前先考虑问题，希望能有大佬看到帮忙解答

JWT

JWT定义了可以表示与认证/授权过程有关的某些共同信息的方式。顾名思义，数据格式是JSON。JWT拥有subject，issuer，过期时间等通用属性。JWT与其他规范（如JSON Web签名（JWS）和JSON Web加密（JWE））结合使用时会变得非常有用。 这些规范不仅提供了授权token通常需要的所有信息，还提供了一种验证token内容的方法，以便它不会被篡改（JWS）和一种加密信息的方法，以使其对于客户端（JWE）。数据格式（及其他优点）的简单性已经帮助JWT成为最常见的token类型之一。

JWT

JWT是无状态的，如果为了实现修改密码踢下线，单设备登录等功能 为其在服务端存储状态显得太多余了，这样为什么不直接用身份令牌呢

为什么要刷新Token?

1、更加安全。直接接给access_token较长时间的有效期，有泄露风险，所以引用refresh_token，有效期长，但权限小。

为什么要靠refresh_token来进行刷新？不能刷新access_token吗？

1.只使用access_token会因一些频繁请求操作造成不断返回新Token，这样会有较大的性能问题(这个其实不成立，只使用access_token可以只在即将过期时刷新)
PS:括号里的操作会增加被盗窃token的可能性和威胁性，可以对比2看
2.refresh_token理论上只在接收和发送时使用两次，减少了网络链路中被盗用的可能
3.通过使用refresh_token使得access_token过期时间可以设置的很短，利用这个特性可以也可以使保存在其中的权限信息可以很快刷新
PS:2是个优点，但是感觉并不明显，3其实算不上优点 ，这个问题感觉还是没有解决

使用refresh_token后，是否两个token都要刷新返回？

不必要一定刷新，可以根据业务需求决定，如不刷新可以保证用户定期重新登录，如果刷新要考虑废弃旧refresh_token的情况，这似乎又需要储存在redis中。

基于access_token和refresh_token 如何实现互踢下线？

登录时把access_token放入redis中，每次刷新时也把redis内的刷新,以用户ID为key
这样第二个设备登录时，就会刷新掉redis内的token,这样需要每次请求都要查询，同时很违反jwt的无状态，不知道有没有其它办法

JWT需要二次加密码？

如果不想Payload 负载中的数据被解码查看的话，需要二次加密隐藏信息。

在access_token过期后，如果同时并发多个请求，该怎么处理？

PS 双Token跟JWT无直接关系，JWT更适用于邮件验证这种情况。