3.4 API 安全性：认证授权加密

3.4 API 安全性：认证授权加密三件套

本节摘要：先验身份（认证）、再判权限（授权）、路上传加密（传输层），是接口安全的三件套。本节讲清认证的四种常见机制（API Key、Basic、OAuth 2.0、JWT）与授权的最小权限原则，再从资源敏感度出发给出"先 HTTPS、再按需认证、最后精细授权"的分级落地顺序。

学习目标

阅读完本节，你应当能够：

1. 区分认证与授权两个概念，并说明各自解决什么。
2. 比较 API Key、Basic、OAuth 2.0、JWT 四种认证机制的强弱与适用场景。
3. 应用最小权限原则做资源级授权。
4. 按资源敏感度给出安全能力的落地顺序。

先把认证、授权、加密三道题分开

安全常被笼统归为"加密 + 登录"，但其实是三道不同的题：

• 认证（Authentication）：你是谁？验身份、拿凭证、发令牌。
• 授权（Authorization）：你能做什么？判定身份对某资源有没有权限。
• 传输加密：路上怎么防窃听？TLS/HTTPS 保障机密性与完整性。

这三者一个都不能少。只认证不授权，登录了一切都能偷看；只加密不认证，来者不拒；只授权不认证，权限判给谁都不知道。下面逐件落地。

二、四种认证机制对照

逐个说关键取舍：

1. API Key：最简单，一个密钥分发即用。但密钥一旦泄露就等于身份泄露，且粒度粗、难以按用户细分权限，适合"机器到机器、低敏感"的场合。
2. Basic Auth：把用户名密码 base64 后放 Authorization 头。base64 不是加密，是编码，明文可解，必须配 HTTPS，否则等于裸奔。适合快速启用已有账号体系的内部低风险服务。
3. OAuth 2.0：真正的授权框架，用户把对某应用的访问权限"委托"出去，拿 access token 访问资源，适合"第三方想读我的数据"这种场景。比重与服务端的授权粒度、token 生命周期管理，复杂度也是四种里最高的。
4. JWT：自包含签名，服务器不需要查 session 就能验身份与声明，和无状态的 REST 天然契合。副作用是签发即不回收、"不能主动撤销"，刷新与黑名单要自己设计。

三、授权的最小权限原则

授权判"能不能做"，铁律是最小权限：只给完成任务所需的最少资源与操作，给多了，一个泄露的令牌就能放大攻击面。

落地到接口上，结合资源归属与角色两个维度：

• 资源归属：GET /users/99/orders 只允许"99 本人或有管理权的人"访问，不能凭"登录了"就放行任意用户的订单。
• 角色/权限：管理员能删、运营能改状态、普通用户只能读属于自己的。用明确的权限检查逐资源判定，而不是"登录就能干啥都行"。

{
  "subject": "user:99",
  "scopes": ["orders:read", "orders:cancel"],
  "resource": "/users/99/orders"
}
​

⚠️ 常见坑：认证通过 = 全部放行（"能登进去就随你"）。越权事故几乎都来自"只验了身份，没验对某资源的权限"。最小权限原则是把这个缝焊住的关键。

把安全三件套的落地顺序画成一张门禁图，一眼看懂该从哪道门入手：

图：安全落地顺序三道门

四、按敏感度分级落地

安全也别图"一步到位加最重的"，成本与敏感度要匹配。给一套分级落地顺序：

1. 全站先上 HTTPS：成本最低、收益最直接，不加它，后面任何认证都是裸奔。传输加密是地基。
2. 按接口敏感度定认证：公开只读接口可以免认证；写操作、个人数据必须认证；越敏感，认证机制越强（从 API Key 升到 OAuth/JWT）。
3. 再上资源级授权：对用户侧数据做归属校验与最小权限，把越权挡在服务器层。

分级的好处是：低成本场景（内部统计、公开目录）不必背 OAuth 的复杂；高敏感场景（支付、个人数据）不会因为图省事而裸奔。安全不是"上最贵的东西"，而是"在每处上够用的东西"。

拿一个具体接口核一遍，这套分级就立住了。公开的图书列表：只上 HTTPS 即可，连认证都可以省。用户自己的订单列表：必须认证，jwt 先放在 Authorization 头，授权时校验"这份订单属于当前令牌所代表的用户"。管理员的用户列表：既要强认证，又要按角色把"删除"这类操作扣住，没权限就回 403。三个接口、三档安全强度，各自的敏感度决定落在哪道门——这就是分级落地最实在的用法。

💡 关键直觉：把安全想成"门禁系统"——先保证每条路都加密（墙），再在每扇门验身份（钥匙），最后按每间房判权限（能不能进）。三道门各司其职，缺一道系统就漏风。

本节要点回顾

• 要点一：认证（你是谁）、授权（你能做什么）、传输加密必须在三处分别落地。
• 要点二：API Key、Basic、OAuth 2.0、JWT 四种机制强度与复杂度递进。
• 要点三：Basic 的 base64 是编码非加密，必须配 HTTPS。
• 要点四：JWT 自包含、无状态，与 REST 契合，但签发不回收，要设计刷新与黑名单。
• 要点五：授权铁律是"最小权限"，只给完成任务所需的最少资源。
• 要点六：按资源敏感度分级落地：先 HTTPS，再按需认证，最后资源级授权。

安全防线就位，下一节给契约装上"加速条款"——缓存机制让读得多的接口跑得更快。