接口暴露出去之后
接口只在公司内部用时，大家图省事，常常一个通用密钥走遍所有服务。一旦接口要给外部、给前端、给第三方用，安全就从可选项变成了必选项——因为你不知道对面是谁、会怎么用。
API 安全的目标不是把接口锁死到没人能用，而是让「该谁用、能用什么、用多少」都清清楚楚。
好用和安全并不矛盾：好的鉴权设计，是让合法用户无感通过，让越界请求当场被拦下。
本文核心知识点
- 认证确认你是谁。
- 授权确认你能做什么。
- 令牌用短期凭证代替长期密码。
- 最小权限只给刚好够用的权限。
- 限流挡住滥用与刷量。
先分清：认证还是授权
安全设计第一步，是把两件常被混为一谈的事分开：认证是「你是谁」，授权是「你能做什么」。先认出人，再决定给他开哪扇门。
| 问题 | 属于 |
|---|---|
| 你是已登录的用户吗 | 认证 |
| 你能修改这条数据吗 | 授权 |
| 这个第三方应用能读你的订单吗 | 授权 |
把这两层分开设计，权限模型才清晰，也方便复用。
令牌：别把账号密码到处传
最危险的做法，是把账号密码直接放进每个请求里传来传去。更稳的方式是用令牌：登录后拿到一个有时效的凭证，后续请求带它，过期再换。
# 令牌的基本思路
1. 用凭据换一个短期令牌
2. 后续请求带上这个令牌，不再传密码
3. 令牌过期后用刷新机制换一个新的
# 即便令牌泄露，窗口也有限，比长期密码安全。令牌要短时效、可吊销，一旦发现异常能立刻让它失效。
最小权限：给刚好够用的钥匙
很多安全事故，不是被攻破了，而是某个本不该有大权限的令牌，恰好被人拿走了。缓解办法是最小权限：每个调用方只拿到完成任务所必需的那点权限。
| 做法 | 好处 |
|---|---|
| 按范围拆分权限 | 读和写分开，只读令牌不能改数据 |
| 限制令牌能访问的资源 | 泄露了也翻不出多大浪 |
| 定期轮换密钥 | 降低长期泄露的影响 |
权限给得刚好，泄露时的爆炸半径就小。
限流与防护：别被刷垮
接口即使认对了人，也可能被滥用——脚本高频刷、恶意爬、把你当免费算力。限流就是给每个调用方一个额度，超出就拒绝。
# 限流的基本策略
- 按调用方或用户设每秒请求上限
- 超出额度返回明确的繁忙提示
- 对敏感接口再加一层频控
# 限流既是防护，也是在保护系统不被自己人刷爆。安全不只是防坏人，也包括防止任何一方把系统用到过载。
传输与密钥：底线不能松
- 所有接口走加密传输，别让凭证在网上裸奔。
- 密钥和令牌不写进代码、不提交仓库、不打进前端包。
- 错误信息别把内部细节抛给外部，避免帮攻击者摸清结构。
这些是底线，做不到上面的鉴权设计都白搭。
安全是设计出来的
API 安全与鉴权的最终目的，是让接口在开放给别人用的同时，风险始终可控。
- 认证与授权分层，谁是谁、能做什么清清楚楚。
- 短期令牌加最小权限，把泄露的代价压到最小。
- 限流加加密传输，挡住滥用、守住底线。
当安全在设计时就长在接口里，而不是出事之后再打补丁，接口才能放心地对外开放。