▎常见的鉴权模型
- OAuth 2.0
- ClientSide
A <-(token)-> B,A -> B - ServerSide
A -> B
> OAuth 2.0
这是一种平台上常见的方法，用户授权去拿它的数据。
是一种用户参与的主动行为。
> ClientSide
Client 不一样，Client 都是向服务端申请一个 token 令牌，再由这个令牌去查信息的。
原因主要是 Client 轻量，不适合保存私钥，也不适合计算 token。
Client 用于用户自己使用网页登录的模式。
> ServerSide
Server 方式，用于两个系统间通信，而 Client 的方式，则用于向手机端签发一个 token。
ServerSide 也有两种常用的方式
- app key、secret 模式
- 公私钥签名模式
- app key、secret 模式
就像是 basic 验证时的用户名密码，secret 就是 digest 了。
因为服务端吗，不经过复杂的链路。也不需要啥安全的。
- 公私钥签名模式
还有一种就是 A 用私钥进行签名，
B 用公钥进行验签。
▎两种类型
平时，我们一个系统里，会有用户和平台两种角色
用户只能看到自己的数据，而平台可以看到整体的数据。
平台 != Admin
> 用户角色的 API
而用户，根据角色不同，又分为
- 用户
- 商家
- 客服/管理员
其各自有着不同的功能和权限。通常我们会用不同的域来对其做区分：
- /uv1
- /mkv1
- /admv1
▎授权模型
根据用户的角色，对应其可以使用的授权模型：
| User | Maker | Admin | APP | |
|---|---|---|---|---|
| ServerSide | Y | Y | Y | Y |
| ClientSide | Y | Y | Y | / |
| OAuth 2.0 | Y | / | / | / |
▎谈谈 APP 授权
> 使用及场景
似乎不常见哪个平台，对自己平台数据有开放 API 的，这些都是内部关键数据。
都是自己的人员，比如说微服务中的同公司其它服务，也就是说这里不用对权限做太多的限制？
> app 的权限范围
如果不设计权限范围的话，那不就乱来了？
app 关联到同户，不然找不到人
> 归属权
- 归属到一个用户
- 一个组织
如果是关联到用户下面，那这和用户的自己的 token，除了权限上的不同，其它都一致了。
> 申请流程
这个应该不能申请，只能后台批。
> auth 定义
app 是关连到用户，还是组织？
表名：tokens / authkeys
字段：
- user_id
- scope
- session_id
- private_key
▎JWT - ServerSide 公私钥签名模式
1 | type MyJWTClaims struct { |
通过 mode 字段标识是一个服务端对服务端的 token
> JWT 定义
jti - serverside 用，表示一次性，uuid
iss - serverside 用，表示是谁，用户是谁
sid - serverside 用，给谁
uid - clientside 用，表示谁
app 模式
iss - ????
jti - 一次性
sid - 表示 app 要用的 key
app 是谁呢？要标识吗？
▎REF::
- Coding 令牌 - https://help.coding.net/docs/member/tokens.html
