PGO-JWT
概念繁多
首先，Authorization/Authentication/Token/BasicAuth/BearerToken/Cookie/Session/RBAC… 等等大批概念，
他们根本目标是想要解决“服务端识别请求者是谁”的问题。但比较难几句话构建起这里的知识框架。
他们之间不是简单的“替换关系”，而是各有所长，又有新老技术更替的关系在里面。
只有讨论具体问题时，可能才有准确的答案，比如 Token 比起 Cookie 可以避免 CSRF 攻击。
又如：Authorization 翻译为“授权”，Authentication 翻译为“认证”，Token 是一种“凭证”。
我们可以造句：用户输入账号密码，经过系统的“认证”后，系统返回一个“凭证”，后续访问其他数据时，都会带着这个“凭证”，这些数据需要系统为这个用户“授权”了才允许用户访问。
而现在比较流行的一种鉴权方案是用 JWT 标准传递的 BearerToken 作为鉴权信息
BearerToken
BearerToken 是一种授权模式，表示”持有即拥有”的令牌。属于 OAuth 2.0 框架的一部分。
“持有即拥有”：任何持有此令牌的客户端都被授予访问权限。
只定义了”持有即拥有”这种特性，但没有规定令牌的具体格式或内容。
session/cookie/token 的区别
- cookie 和 session
- cookie 存储在客户端，每次请求发送给服务端。比如用户 ID/用户名/页面中英文设置状态等等。
- session 由服务端创建，粗暴一点可以理解为“基于本来无状态的 HTTP 协议但后端保存了用户的状态”
- 两者一般都结合使用
- 可以简单看作前后端分别有一份数据存储了用户当前的一些状态。
- 存在 cookie 的方便前端修改和后端读取，而存在 session 的是稍微隐秘的数据。
- 通过 sessionId 把前后端的数据关联起来。
- 这些“状态”本质上也是“缓存”。（空间换时间）
- token
- 存储尽量少的数据，比如只包含用户 ID。其他内容由前后端自己通过其他方式来存储。（时间换空间）
- 比起 Cookie， token 是准们为了避免 CSRF 攻击而设计的。
和 JWT 的关系：BearerToken 是传输方式，JWT 是内容格式
JWT
JWT (JSON Web Token) 是一种开放标准 (RFC 7519) 用于在各方之间以 JSON 对象安全地传输信息。 常见作为 Bearer Token 的实现形式。 也可以用于各种场景，不限于身份验证。
它由三部分组成：
- Header - 包含令牌类型和签名算法
- Payload - 包含声明 (claims)，通常是用户信息和其他数据
- Signature - 用于验证消息在传输过程中没有被更改
以下是标准的字段，这些字段能被大部分 JWT 库识别和处理：
| 字段名 | 缩写 | 描述 |
|---|---|---|
| Issuer | iss | 签发者 |
| Subject | sub | 主题(通常是用户 ID) |
| Audience | aud | 接收方 |
| Expiration | exp | 过期时间(Unix 时间戳) |
| Not Before | nbf | 在此之前不可用(Unix 时间戳) |
| Issued At | iat | 签发时间(Unix 时间戳) |
| JWT ID | jti | JWT 唯一标识符，用于防止重放攻击 |
PGO 实现
TODO 基于 kratos 实现 VS 基于 golang-jwt 实现