上一节我们说了Token的自解释性生成算法、Token信息的在服务端的存储以及客户端携带Token请求API时服务端的Token认证逻辑。
这节我们继续讲Token的刷新和主动踢人下线
首先Token为啥刷新呢？很简单为了安全性用户AccessToken的时效性会相对较短，保证Token被其他恶意用户拿到后也不能长时间用它来浏览用户的数据。
即然有效期短那就得有合理的方式让用户的Token能够被刷新，不然用户使用产品期间隔一段时间就得登录一次，一天登录好几次，用户体验可想而知，定是不会好的。
为什么要有刷新Token
在我们的用户认证体系中，当用户登录成功后，在服务端存储以下的Token信息和用户会话信息
这里我们设计了两种Token：AccessToken以及RefreshToken，AccessToken专门用户来接口请求中验证请求的用户身份，我们上面说过为了安全考虑它的时效比较短一般 0.5h ～ 2h，到期后客户端可以用RefreshToken来刷新获得新的Token信息。
RefreshToken的时效一般设的较长10 ～ 30天都可以，假设用户首次登录后过了几天再来使用应用，客户端仍能通过RefreshToken来刷新Token信息，用户在短期未使用产品的情况下仍能保持住登录态，不至于出现隔几天再用每次都得重新登录的情况。
所以两个Token，AccessToken 时效短，RefreshToken 时效长，两者结合，在安全性和用户体验上都有一定保证。
在上节用户 Token 的派发、存储和认证开发的功能中，项目的用户登录系统时，服务端存储了上述Token和会话信息后会向客户端下发以下图示中的Token字段。
除了上面这张用户登录的情况，当客户端进行Token信息的刷新时，这些Token字段也会更新并返回给客户端，也就是说刷新Token信息后除了AccessToken会更新外，RefreshToken也会刷新，用户登录态的可保持时间又往后延长了一个新的周期。与此同时旧的RefreshToken我们并不会直接删，而是设置延迟几个小时删除，为什么这么做呢？后面告诉你答案。我们先看一下Token刷新逻辑的实现。
Token刷新逻辑实现
我用下面这个顺序图说明了整个Token刷新的逻辑。
大家把这张图中描述的Token刷新逻辑好好地看一下，通过这张图可以看出来，刷新逻辑与生成逻辑只有两处不一样：
与Token生成的差异点、Token刷新在Go项目中的代码实现细节、如何实现Token被盗检测和踢人下线，这些内容在我的专栏《Go项目搭建和整洁开发实战》中都已更新，请扫码订阅专栏查看完整版
项目中有完整的实现步骤以及Token生成、验证和刷新的测试用例供我们边调试代码边理解掌握这些知识。
总结
本节的代码版本号为c11，加入项目后访问 https://github.com/go-study-lab/go-mall/compare/c10...c11 能看本章节的详细代码。
Token的主要逻辑到这里就开发完成了，接下来我们把它接入到用户登录的流程中去，另外现在的Token体系还不够完善，因为对于用户登出、重置密码等需要主动过期Token和清除Session的逻辑我们还没有覆盖到，这些我们会在接下来的几节中开发相应的功能时再去完善。
这些项目实战教程在专栏中也已经更新，感兴趣的请扫码订阅专栏阅读
本专栏分为五大部分，大部分内容已经更新完成
-
第一部分介绍让框架变得好用的诸多实战技巧，比如通过自定义日志门面让项目日志更简单易用、支持自动记录请求的追踪信息和程序位置信息、通过自定义Error在实现Go error接口的同时支持给给错误添加错误链，方便追溯错误源头。
-
第二部分：讲解项目分层架构的设计和划分业务模块的方法和标准，让你以后无论遇到什么项目都能按这套标准自己划分出模块和逻辑分层。后面几个部分均是该部分所讲内容的实践。
-
第三部分：设计实现一个套支持多平台登录，Token泄露检测、同平台多设备登录互踢功能的用户认证体系，这套用户认证体系既可以在你未来开发产品时直接应用
-
第四部分：商城app C端接口功能的实现，强化分层架构实现的讲解，这里还会讲解用责任链、策略和模版等设计模式去解决订单结算促销、支付方式支付场景等多种多样的实际问题。
-
第五部分：单元测试、项目Docker镜像、K8s部署和服务保障相关的一些基础内容和注意事项
扫描上方二维码或者访问 https://xiaobot.net/p/golang 即刻订阅