从安全、开发、产品三个角度反对用refresh_token续期access_token的观点

发布时间:2023年12月22日

说明:

access_token: 服务端与客户端通信,有时服务端需要知道客户端的身份,就会用到access_token来用于验证身份。
refresh_token: 但为了保证安全token会设置过期时间,如果直接过期,相当于用户或调用端正在使用产品,突然间就退出登录了,这种产品体验很差,于是有了refresh_token。
简易流程: 登录后,服务端返回两个token,用于确定身份的access_token(短时间过期),和刷新access_token的refresh_token(长时间过期),请求接口时,如果access_token未过期则正常使用;当access_token过期但refresh_token未过期,则使用refresh_token获取新的access_token;如果refresh_token过期,则本次会登录过期,退出。

反对理由:

安全角度:

滥用问题: refresh_token是用来生成新的access_token而生的(字面意思叫刷新令牌),所以它就像一个token机关枪一样,突突突可以生成任意多个access_token,现在黑客攻击花样层出不穷,所以这个refresh_token因各种攻击或漏洞泄露出去很不安全。
全局鉴权问题 若有逻辑漏洞,用户主动退出登录致使access_token1销毁,能不能保证这个refresh_token创建的access_token_2也失去作用呢,顾头也得顾腚。

开发角度:

实现繁琐: 就一个登录还要两个token,虽然不复杂,但是繁琐。
存储问题: token是不用存储,但是为了安全,用户退出时access_token未过期,则需要在服务端存储一个黑名单,如果服务端在遇见这个access_token则直接拒绝这次访问。并附加一个过期时间,这个过期时间设置的一般是略大于或等于
access_token的过期时间,access_token需要这个解决方案,那么refresh_token也需要解决,数据量小还好,数量大这又是个问题。

产品角度:

这是个概率问题,也是个矛盾问题,就要看开发者怎么实现了,如果refresh_token和asscess_token过期直接退出登录,则用户可能正在使用或刚刚在用,然后会话就突然退出登录了,产品体感很差。
如果开发者考虑到refresh_token自动续期,那么都续期,refresh_token是不是又显得多余?是不是一个access_token自动续期就行了?

解决方案:就一个access_token即可。

续期问题怎么办?

现在很多access_token都用jwt,token里面可以塞一些数据,其中一个就是过期时间,服务器处理数据前,可在服务端判断token是否临近过期,如果临近过期直接自动生成新的access_token等逻辑处理完成,一并返回,客户端无感知静默续期,如果不用jwt,使用自定义token生成策略,原理也差不多。

续期的边界问题怎么办?

例如token过期时间30分钟,用户在21分钟和31分钟做了请求,服务端设置自动续期的时间点是>=25分钟,此时token又没有自动续期,用户在31分钟时仍旧会退出登录,用户体验还是不好。解决方案有两个,token距离过期时间的阈值设置的大一点,比如设置20分钟,这样可以自动续期避免边界问题。二是让前端解析token(一般是jwt),每分钟执行一次,前端检测到token块过期了,异步请求接口自动续期,只要前端能解析,是否快过期了客户端最清楚。

安全问题呢?

滥用问题不存在。
全局鉴权问题,仍旧需要让服务端把未过期但弃用的token放入黑名单中,并设置过期时间。

开发问题呢?

一个token相对简单。
存储问题:仍旧需要让服务端把未过期但弃用的token放入黑名单中,并设置过期时间,该存的还得存。

产品问题呢?

做好自动续期,用户体感就好了。

总结:

可见access_token也不是完美的,但相比refresh_token更方便也更安全,也确实难以找出一种完美的解决方案。

大家怎么看?

文章来源:https://blog.csdn.net/weixin_42100387/article/details/135141093
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。