这是我参与「第五届青训营 」伴学笔记创作活动的第 32 天
本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的 专栏 中逛逛看有没有你想要的东西。
- 第 1 篇 - Kitex 口水话
- 第 2 篇 - Hertz 口水话
- 第 3 篇 - 微服务口水话
- 第 4 篇 - Kafka 口水话
- 第 5 篇 - BMQ 口水话
- 第 6 篇 - RecketMQ 口水话
- 第 7 篇 - 数据库口水话
- 第 8 篇 - RDBMS 口水话
- 第 9 篇 - TOS 口水话
- 第 10 篇 - tinyTikTok 环境配置
- 第 11 篇 - tinyTikTok 规范设计
- 第 12 篇 - tinyTikTok 项目管理
- 第 13 届 - tinyTikTok 认证授权
- 第 14 篇 - tinyTikTok 服务功能
- 第 15 篇 - tinyTikTok 测试分析
- 第 16 篇 - tinyTikTok 项目总结
放在前面的话
看到 /login 接口就应该想到认证授权，其实认证授权是两个不同的服务：认证——身份认证；授权——资源授权。
但我这里只打算简单写写认证功能（因为这篇文档是补的，对照着完成度来写吧hhhh
认证的分类
这里只介绍两种：OAuth 和 Bearer。
先说说 Bearer 吧，也是我们（信安专业）常说的令牌，这是业内最流行的认证方法，核心便是令牌 token。token 是一个加密字符串，通常由服务端根据密钥生成。客户端在请求服务端时，必须在请求头中确定认证方式为 Bearer 。服务端收到请求后，解析出 token，并校验 token 的合法性，如果校验通过，则认证通过，否则反之。
比起 Basic 等其他认证方式，Bearer 几乎是最安全的认证方式，但即使如此，也需要配合 HTTPS 一起使用才能认为大多数场景下是安全的。（评分标准的安全性效果无非也是到这里
那为什么要聊聊 OAuth 呢？确切地说是 OAuth 的密码式。
因为客户端的请求是直接把 password，token 等敏感信息直接放 URL 里的（-_-\\\
但毕竟仅仅是青训而已，说到底只是一个 toy program 罢了，可以理解客户端的骚操作，或者，也可以把它理解为这是一个高度信任的场景，所以敢这样做。
whatever，我第一反应想到了 OAuth 的密码式，纵观四大认证方式（Basic、Digest、OAuth 和 Bearer），只有 OAuth 的密码式既包含了 password 和 token。
但这里还有一个需要注意的地方，安全的 OAuth 应该还有一个第三方机构用来发放和校验令牌，而这里我们可以把它看作服务端的一个认证服务。
既然选择了 OAuth 密码式作为认证方式，我们便需要考虑 token 的生成和验证问题：
- token 生成：利用中间件是最明智的方法，项目了用了 gin-jwt，因为最开始忘记抓包观察了，其实用 oauth2 会更合适些；（oauth2 不会总是校验 token，更适合高并发场景
- token 验证（这部分没来得及做，简单说一下）：添加一个授权服务，用 redis 去缓存 token，即使服务端崩溃，在没做优雅退出的情况下，也不用担心 token 失效（它不能总是一直崩溃吧55555），然后根据不同的授权策略去获取资源。
放最后的话
要是没解释清楚可以在评论里 Q 我。
最后简单提一下资源授权的策略：权限控制列表（ACL，Access Control List）；自主访问控制（DAC，Discretionary Access Control）；强制访问控制（MAC，Mandatory Access Control）；基于角色的访问控制（RBAC，Role-Based Access Control）；基于属性的权限验证（ABAC，Attribute-Based Access Control）。
想了解的出门右转 Google 不送～
