本文主要是介绍从安全、开发、产品三个角度反对用refresh_token续期access_token的观点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
说明：
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更方便也更安全，也确实难以找出一种完美的解决方案。
大家怎么看？
这篇关于从安全、开发、产品三个角度反对用refresh_token续期access_token的观点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
