3、API认证与授权：API Key机制、OAuth 2.0流程、JWT令牌生成与验证、权限粒度控制
在评分通道API的发布与监控体系中，认证（Authentication）与授权（Authorization）是保障数据安全与合规访问的基石。认证解决“你是谁”的问题，授权解决“你能做什么”的问题。本章将深入剖析四种核心机制：API Key、OAuth 2.0、JWT 以及权限粒度控制，帮助你在不同场景下做出最佳选择。
3.1 API Key 机制：轻量级身份标识
API Key 是最简单的认证方式，通常由服务端生成一个唯一的字符串（如 sk-abc123xyz），客户端在每次请求时通过 Header 或 Query 参数携带。适用于服务端到服务端（M2M）的内部调用或低风险场景。
| 特性 | 说明 |
|---|---|
| 生成方式 | 服务端随机生成，通常包含前缀（如 sk-）以标识类型 |
| 传递方式 | HTTP Header（如 Authorization: Bearer sk-xxx）或 Query 参数 |
| 生命周期 | 永久有效或可设置过期时间，支持手动吊销 |
| 适用场景 | 内部微服务调用、开发测试环境、第三方简单集成 |
| 安全风险 | 泄露后需立即吊销；无法区分用户身份，仅识别应用 |
最佳实践：API Key 应视为敏感信息，存储在环境变量或密钥管理服务（如 AWS Secrets Manager）中，切勿硬编码在代码仓库中。建议配合 IP 白名单或请求频率限制使用。
3.2 OAuth 2.0 授权流程：标准化的委托授权
OAuth 2.0 是一种授权框架，允许第三方应用在用户授权后，获取有限的资源访问权限。评分通道API推荐使用 授权码模式（Authorization Code Flow） 和 客户端凭证模式（Client Credentials Flow）。
核心角色与流程
- 资源所有者（Resource Owner）：用户，拥有数据访问权。
- 客户端（Client）：第三方应用，请求访问资源。
- 授权服务器（Authorization Server）：负责认证用户并发放令牌。
- 资源服务器（Resource Server）：托管受保护资源，验证令牌。
授权码模式（推荐用于前端+后端应用）：
1. 客户端引导用户跳转至授权服务器登录。
2. 用户同意授权后，授权服务器返回授权码（Authorization Code）。
3. 客户端用授权码向授权服务器换取访问令牌（Access Token）和刷新令牌（Refresh Token）。
4. 客户端使用 Access Token 访问资源服务器。
1. 客户端引导用户跳转至授权服务器登录。
2. 用户同意授权后，授权服务器返回授权码（Authorization Code）。
3. 客户端用授权码向授权服务器换取访问令牌（Access Token）和刷新令牌（Refresh Token）。
4. 客户端使用 Access Token 访问资源服务器。
3.3 JWT 令牌生成与验证：无状态认证的核心
JSON Web Token（JWT）是一种紧凑的、自包含的令牌格式，常用于 OAuth 2.0 的 Access Token。它由三部分组成：Header、Payload、Signature。
JWT 结构示例
// 编码后的 JWT
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IuW8oOS4iSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTY4MDAwMDAwMCwiZXhwIjoxNjgwMDAzNjAwfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c| 部分 | 内容 | 说明 |
|---|---|---|
| Header | {"alg":"RS256","typ":"JWT"} |
声明签名算法（如 RS256、HS256）和令牌类型 |
| Payload | {"sub":"1234567890","name":"张三","role":"admin","iat":1680000000,"exp":1680003600} |
包含声明（Claims），如用户ID、角色、过期时间 |
| Signature | 对 Header 和 Payload 的签名 | 使用私钥（RS256）或密钥（HS256）生成，防止篡改 |
JWT 验证流程
- 资源服务器从请求中提取 JWT（通常从
Authorization: Bearer <token>）。 - 使用公钥（RS256）或密钥（HS256）验证签名是否匹配。
- 检查
exp（过期时间）和nbf（生效时间）等时间声明。 - 从 Payload 中提取用户身份和权限信息，用于后续授权判断。
安全警告：JWT 的 Payload 是 Base64 编码而非加密，敏感信息（如密码、信用卡号）严禁放入 Payload。始终使用 HTTPS 传输，防止令牌被中间人截获。
3.4 权限粒度控制：从粗放到精细
权限粒度控制决定了 API 访问的精细程度。评分通道API推荐采用 RBAC（基于角色的访问控制） 与 ABAC（基于属性的访问控制） 相结合的策略。
权限粒度层级对比
| 粒度级别 | 描述 | 示例 | 适用场景 |
|---|---|---|---|
| API 级别 | 控制能否访问某个 API 端点 | 允许调用 POST /api/scores |
基础权限划分 |
| 资源级别 | 控制能否操作某个具体资源 | 仅允许读取 GET /api/scores/{userId} |
多租户系统 |
| 字段级别 | 控制能否查看或修改某个字段 | 隐藏 score 字段中的 internalNote |
数据脱敏、隐私合规 |
| 操作级别 | 控制具体操作（CRUD） | 允许创建评分，禁止删除 | 精细化权限管理 |
RBAC + ABAC 组合策略
- RBAC：定义角色（如管理员、审核员、只读用户），每个角色绑定一组权限。
- ABAC：在 RBAC 基础上增加动态属性判断，如时间、IP 地址、资源所属部门。
评分通道API权限示例：
- 角色：
- 角色：
- ABAC 规则：
- 角色：
score_admin → 所有评分 API 的读写权限。- 角色：
score_reviewer → 仅可读取和审核评分，不可修改评分标准。- ABAC 规则：
score_reviewer 在非工作时间（18:00-08:00）只能读取，不能审核。
3.5 四种机制选型对比
| 机制 | 认证/授权 | 状态 | 安全性 | 复杂度 | 推荐场景 |
|---|---|---|---|---|---|
| API Key | 认证 | 有状态（服务端存储） | 低（易泄露） | 低 | 内部服务、开发测试 |
| OAuth 2.0 | 授权 | 有状态（授权码） | 高 | 中 | 第三方应用、用户授权 |
| JWT | 认证+授权 | 无状态 | 中（依赖签名算法） | 中 | 分布式系统、微服务 |
| RBAC/ABAC | 授权 | 有状态/无状态均可 | 高 | 高 | 多租户、复杂权限场景 |
推荐组合：评分通道API建议采用 OAuth 2.0（授权码模式） 发放 JWT 作为 Access Token，并在 API 网关层结合 RBAC + ABAC 实现精细权限控制。API Key 仅用于内部健康检查或临时调试。