2. 基础概念：密钥、权限、令牌、签名、加密
好，咱们正式开始搭地基。这一章讲的是整个模型里最底层的五个概念。我见过不少团队，一开始就急着画接口、写代码，结果到后面发现「诶？密钥和令牌到底谁管谁？」—— 又得回头重来。所以，先把这几个东西掰扯明白，后面省大事。
2.1 密钥：你手里的那把锁
密钥说白了就是一串秘密数据。它可以是 128 位、256 位的随机字节，也可以是 RSA 的私钥文件。它的作用很简单：证明「你是你」，或者保护「你的东西」不被别人看见或篡改。
我个人习惯把密钥分成两种场景来看：
- 对称密钥：加密和解密用同一把。快，但分发麻烦。我跟 A 共享一个密钥，如果 A 把密钥泄露了，整个世界都能解密我的消息。
- 非对称密钥对：公钥加密，私钥解密。公钥可以随便发，私钥打死不外传。你在网上购物用的 HTTPS，底层就是这套逻辑。
2.2 权限：谁可以做什么
权限不是一个能「握在手里」的东西，它是一条规则：「用户 X 可以对资源 Y 执行操作 Z」。你想想看，如果你设计了接口但没有权限控制，任何调用方调用你的接口都能删库 —— 那你的密钥再强也没用。
我常用的权限模型就这么几种：
| 模型 | 说明 | 适用场景 |
|---|---|---|
| ACL（访问控制列表） | 每个资源绑定一个用户/操作列表 | 文件系统、小规模系统 |
| RBAC（基于角色） | 用户 → 角色 → 权限，三层结构 | 企业内部系统、管理员面板 |
| ABAC（基于属性） | 根据用户、资源、环境属性动态判断 | 云服务、微服务架构 |
2.3 令牌：一次性的通行证
令牌（）就像演唱会门票。它本身不证明你是谁，但它证明你在某个时间段内，可以入场。在接口设计里，令牌通常是个加密的字符串，由服务端签发，客户端保存并在请求中携带。
常见的令牌类型：
- JWT（JSON Web ）：自包含的令牌，里面存着用户 ID、过期时间、签名。服务端不需要查库就能校验。
- Opaque ：就是一段随机字符串，服务端必须去数据库查才能知道它代表谁。
- Refresh ：长期有效（比如 7 天），用来刷新短期的 Access 。
我曾经踩过一个坑：JWT 里放了太多敏感信息，比如用户手机号、身份证号。其实 JWT 的 payload 只是 Base64 编码，不是加密的。只要拿到 JWT，任何人都能解码出来。从那以后，我都在 JWT 里只放 `user_id` 和 `scope`。
2.4 签名：证明这个消息没被改过
签名和加密是两回事。签名的作用只有一个：防篡改、防抵赖。
举个例子：我发给你一条消息「转账 1000 元」，如果我给这个消息附上我的私钥签名，那你只需要用我的公钥验证一下就知道：第一，这确实是我发的；第二，消息内容没人改过。
在接口设计里，签名通常用在：
- API 请求签名：客户端用密钥对请求参数 + 时间戳 + 随机数做签名，服务端验签。防重放、防伪造。
- JWT 令牌签名：服务端签发 JWT 时用密钥签名，客户端拿回来验签就知道 JWT 是否被篡改。
- 消息队列中的签名：保证生产者和消费者之间的消息完整。
HMAC-SHA256（对称签名，速度快）或者 ECDSA（非对称签名，安全性高）。别再用 MD5 做签名——那东西早就不安全了。
2.5 加密：让第三只眼看不见
加密解决的是「保密性」问题。签名和加密经常配合使用：先加密确保内容别人看不懂，再签名确保内容没被改过。
我画一个简单的对比表，帮你快速区分：
| 概念 | 目的 | 能不能看到原文 |
|---|---|---|
| 签名 | 防篡改、验证身份 | 能（签名不隐藏原文） |
| 加密 | 保证只有授权方阅读 | 不能（原文被混淆） |
实际开发中，我建议你这么用：
- 传输层：用 TLS 加密整个通道。这是最基础的，别省。
- 数据持久化：敏感字段（如密钥、令牌）用 AES-256-GCM 加密后存数据库。
- 端到端加密：如果数据经手多个系统，用非对称加密 + 对称密钥包裹。
2.6 五者之间的关系：一张图说清楚
下面这张 SVG 图把五个概念串在一起，标出了它们的核心关系和流向。你看完这张图，就知道整个知识体系的骨架长什么样了。
2.7 总结一下
这一章讲的东西，就是你今后设计的「原料」：
- 密钥：安全的根，一切信任的基础。
- 权限：业务规则，决定能干什么。
- 令牌：临时凭证，承载身份和授权信息。
- 签名：确保消息完整性，防篡改。
- 加密：确保消息机密性，防窃听。
记住一个原则：密钥自己是不会说话的，它需要签名、加密、令牌这些「工具」去发挥作用。而权限决定了这些工具能被谁用、怎么用。把这五个概念的关系烂熟于心，你后面的接口设计才不会跑偏。