徐曙辉置顶2022-10-28 来自北京Q1：在token过期很短的时候，通过refresh_token频繁更新token，怎么实现对用户实时管理？是不是还是跟用户人数相关，一般这种场景是后台系统，删除一个用户后该用户账号立刻不能登录，后台人数比C端人数少很多，所以管理起来代价比较小，更看重权限安全，放在缓存中进行管理。 A: 如果我来做快速更换昵称的功能，两种方式， a.在用户修改昵称后，内存中加入个用户标识，解析token后读取该标识，有则返回特定code，让客户端重新拿token。甚至可以不用客户端参与，返回301重定向到获取新token的路由。 b. token里面不存用户信息，只存用户ID，需要用户信息的时候从缓存读。作者回复: 你好，徐曙辉，很高兴收到你的再次留言 对于session 方式来说，由于用户每次请求都会读取session cache，客户端本地是不会保存token，所以不存在token内用户头像更新不及时问题。可以说后台系统用session管理用户很方便，因为这个可以做到用户实时管理，当我们禁用用户的时候把session的缓存登陆标志删掉即可。不过这个方式适合少量用户，对于QPS超过10w QPS请求的API则不太适合。 所以使用token方式来签名发给客户端，客户端请求其他子系统的时候，会带上它，子系统只要验证这个token的签名就不需要再去用户中心问一句。所以token使用后，用户中心不会被其他子系统频繁请求，但是也导致token发出去没法再次更改，即使我们用户中心给他拉黑了，其他子系统只认印章，不会过来问问。 同时为了方便token内会保存当前用户一些基础信息，减少其他系统过来询问的次数，这导致，用户更新头像，token没更换，是不会同步更新的 第一个很暴力，但是很有趣～ 第二个方式也很有趣，同时补一个技巧我们可以通过 设定 固定网址 user/用户uid/heaer.jpg方式直接获取用户头像，这样也不用考虑更新问题了
共 10 条评论3
极客2022-10-28 来自北京客户端可以缓存修改后的昵称，直到更换了access token再清除缓存，类似弹幕本地先发送让用户自己认为发送成功了作者回复: 你好，极客，感谢你的留言，这个思路很有意思，是个方法，印象里这个技巧对于读多写多的服务的客户端也会做类似的事情
9
7S2022-10-28 来自北京access_token由于安全问题设置过期的时间非常短，但是refresh_token有效时间非常长，如果refresh_token被泄漏掉，是不是能一直刷新access_token呢。。作者回复: 你好，7S，很高兴收到你的思考，关于这里有一些特殊的小技巧，如请求时带上一些客户端特征，如：请求更换access_token时，带上的refresh_token的请求 同时 需要特殊的签名，存储在本地的token不用明文保存，与服务端通讯时用特殊协议加密等～
共 3 条评论4
小林coding2022-11-15 来自北京PAYLOAD 中定义的 token 发放时间 iat 字段的值是绝对时间戳，如果服务端的系统时间被往前修改了，这时在校验token是否过期的时候，是不是还需要增加一个处理：如果「当前时间戳 < token 发放时间戳 」，就认为 token 过期了。作者回复: 你好，小林，经常看你的公众号，这里建议如果只是一两秒建议忽略，原因在于，我们的服务器时间都是有误差的即使使用ntp定期同步也是存在误差，有时相差一两秒是很常见的，并且https也是基础时间做的加密，如果时间误差太大是无法通讯的。
3
吴晨辉2022-10-31 来自北京很高兴第二次回答问题 传统sessoion会导致用户中心缓存大，耦合度高，但实时性强 jwt加密策略耦合度低，但是实时性不高 那么可以结合两个方式，优先读取token 加密字段，然后利用用户id关联session cache覆盖 考虑到session缓存成本，可以只缓存实时性强的字段，或者用vip制度，用户充钱越多，缓存的东西越多 核心思想就是成本增效作者回复: 最后一句很棒，支持，笑
共 2 条评论3
👽2022-12-27 来自北京我的理解是，token中应该只存放和session生命周期同步的操作。比如：用户Id和权限。这两个东西，在用户session的生命周期内一般来说是不会变的。翻译一下，token代表着：你是谁，你能做什么。能做到这两个事情就够了。而不应该去单独关注用户的扩展信息。 至于昵称，我觉得应该单独放缓存中。通过用户ID获取。因为昵称当前token下修改还好说，如果跨token呢？比如web端修改了昵称web端端token可以立马换一个新的，移动端怎么办呢？所以我认为，昵称，头像，这种会修改的信息不应该放到token体里。作者回复: 你好，alien，确实如此，而很多业务为了方便，token有额外一段在结尾放附加消息
1- 林晓威2022-11-07 来自北京老师好，请问光使用base64加密是不是不太安全？这样别人不是很容易知道你用什么加密算法了
作者回复: 你好，林晓威，很高兴收到你的提问，这个算法重点并不是这个payload区，payload这里只是附带的数据，只是为了方便业务使用，事实上这个核心在于签名和过期时间，由于密钥是只有服务端有，所以签名是不能伪造的，如果到子业务这里验证签名是正确的密钥加密的，那么代表token的payload的内容肯定是服务器发放的，传输的用户无法更改，如果更改了就会和签名核对不上，通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息，如果有不能公开的信息可以再做一层加密后再放入payload
1 
seker2023-08-16 来自广东徐老师，请问，用于token加密头中的常用加密算法有哪些呢？作者回复: 你好，seker，可以参考这个列表 https://jwt.io/libraries
- 无问西东2023-07-26 来自上海你好，客户端保存token如何保证不被其他应用窃取呢
作者回复: 你好，这个看对安全要求程度。太过复杂会有些难用，简单的方式token可以加密保存在本地存储或数据库内如localstorage，sqlite，每次请求再次加密传输，定期更新短期token等
李坤鹏2023-07-08 来自广东如果用户中心和周边服务不属于一个信任域，需要将 JWT 签发能力限定在用户中心，但是和周边服务的关系又没有疏远到需要使用 OAuth 授权的程度，那么是否可以使用 RS256算法替代 HS256 算法呢？这样子周边服务无法自己颁发 token，但又可以自己独立验签，相当于牺牲一部分性能换取安全性。这种做法在业界是可接受的方案吗？作者回复: 这里我了解不多，不过从你的描述来看我理解是可以的。 具体有什么限制和问题需要一起坐下来看和尝试。