从这一节开始我们来演示如何按照思路实现一个用户认证体系，本节我们主要关注用户Token的生成、存储以及认证，下一节我们会专注Token的刷新、主动踢人下线和防盗检测。
本节内容大纲如下：
图片
Token串的自解释性和生成规则
我们的用户认证体系里有两种Token：AccessToken以及刷新它用的RefreshToken。
图片
无论Token信息在产品的服务端有哪些构成信息，我们发放给客户端的都是随机的字符串，客户端访问服务端API时会携带着Token串来访问。
Token串的生成算法多种多样，简单的MD5一下子，复杂的会各种加密，在我们项目中使用的则是一个兼具安全和可解释性的Token生成算法。
为每个用户生成的Token的算法，会用大端序的排列方式把用户ID放到固定位置后再进行AES加密，同时再追加一个类似salt串的随机字符串作为前缀，把16进制转换成字符串后一共有40个字符。
图片
因为生成Token时UserID放在了固定的字节位置，所以服务端拿到Token后可以解密后再把UserID取出来，这样的话Token就具有了自解释性，在系统存储挂掉的降级处理，或者是大数据分析应用日志、归因用户行为时都有一定帮助。
解析Token的代码在教程里就不再占用篇幅了，大家订阅加入项目后访问下面GitHub仓库的代码文件可查看详细细节。
- Token反解析出UserID的代码实现
Token的生成和存储
Token生成的流程解读
用户登录授权，在给用户发放Token前，服务端会存储三份信息用于会话管理和认证。它们分别是AccessToken、RefreshToken 和 UserSession 的缓存信息，其缓存结构如下：
图片
这个我们在上一节讨论过，其中UserSession是为用户的每个登录过的平台单独维护一份Session信息，根据它们的结构特点，我们选择对三种缓存采用以下结构：
- AccessToken、RefreshToken 缓存以各自的Token值做为缓存Key的关键要素，使用Redis String存储JSON格式的Token信息
- UserSession使用UserId做为缓存Key的关键要素部分，使用Redis 的Hash存储，Hash中以每个登录平台的Platform名为字段Key，存储相应用户JSON格式的Session信息，这样多个平台登录后的会话不会相互干扰。
Token生成逻辑的流程和内部细节我用一个顺序图给大家做了梳理，还有详细的代码指南
图片
项目中有完整的实现步骤以及Token生成、验证的测试用例供我们边调试代码边理解
Token的校验
拿我们上面获得的AccessToken来试验Token的校验，因为需要在Header中带上Token， 需使用curl来发起请求，大家自己测试时可选择使用POSTMAN等工具。
curl --header "Content-Type: application/json" \
--header "go-mall-token: 3d7454dd7fe557917a0c195fceebd8c786acc97e" \
http://localhost:8080/building/token-auth-test请求的结果如下：
图片
大家加入项目后动手实践时可以故意把Token写错看一下其他效果。
总结
本节的代码版本号为c11，版本切换操作命令如下：
git fetch --tags
git checkout tags/c11访问 https://github.com/go-study-lab/go-mall/compare/c10...c11 能看本章节的详细代码。
图片
