4. 认证与授权机制：API Key、Bearer Token、OAuth2.0基础、签名算法

任务调度平台的 OpenAPI 接口暴露在公网或内网中，必须通过认证与授权机制来确保只有合法调用者才能访问资源。本章深入剖析四种主流机制：API Key、Bearer Token、OAuth2.0 基础流程以及签名算法，帮助你在实际开发中做出正确的安全选型。

4.1 认证 vs 授权：核心区别

4.2 API Key：轻量级身份标识

API Key 是最简单的认证方式，通常是一串固定长度的字符串（如 sk-xxxxxxxxxxxxxxxx），由平台生成并分配给调用方。

• 传输方式：放在 HTTP Header 中，例如 X-API-Key: sk-abc123，或作为查询参数 ?api_key=sk-abc123。
• 优点：实现简单，适合服务端到服务端的内部调用。
• 缺点：静态密钥容易泄露；无法细粒度控制权限；难以撤销单个客户端。
• 调度平台最佳实践：API Key 仅用于识别调用方身份，权限控制应结合 IP 白名单或角色绑定。

// 请求示例：使用 API Key 认证
GET /api/v1/tasks HTTP/1.1
Host: scheduler.example.com
X-API-Key: sk-2a3b4c5d6e7f8g9h

4.3 Bearer Token：基于令牌的认证

Bearer Token 是一种更安全的临时凭证，通常使用 JWT（JSON Web Token）格式。客户端在登录或换取令牌后，在后续请求的 Authorization 头中携带该令牌。

• 格式：Authorization: Bearer <token>
• 生命周期：Token 通常有过期时间（如 1 小时），过期后需刷新。
• 优势：无状态（服务端无需存储会话）；可携带用户信息与权限声明（Claims）。
• 调度平台场景：用户通过 Web 控制台登录后，前端使用 Bearer Token 调用 OpenAPI。

// 请求示例：使用 Bearer Token 认证
GET /api/v1/tasks/123 HTTP/1.1
Host: scheduler.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

4.4 OAuth2.0 基础：授权框架

OAuth2.0 是一个开放授权标准，允许第三方应用在用户授权的前提下，有限度地访问用户资源。任务调度平台通常使用 客户端凭证模式（Client Credentials） 或 授权码模式（Authorization Code）。

4.4.1 四种授权模式对比

4.4.2 客户端凭证模式流程（调度平台最常用）

1. 客户端使用自己的 client_id 和 client_secret 向授权服务器请求 Token。
2. 授权服务器验证凭证，返回一个 access_token（Bearer Token）。
3. 客户端携带 access_token 调用任务调度平台的 OpenAPI。
4. 平台验证 Token 的有效性与作用域（Scope），执行授权检查后返回数据。

4.5 签名算法：防篡改与身份验证

签名算法通过对请求参数进行哈希计算，生成一个不可伪造的签名，附加在请求中。服务端使用相同的算法和密钥重新计算签名，比对一致则请求合法。这在 API Key 静态传输风险较高时尤为重要。

4.5.1 常见签名算法

4.5.2 签名生成步骤（以 HMAC-SHA256 为例）

1. 构造待签名字符串：将 HTTP 方法、请求路径、查询参数、请求体（若有）按约定顺序拼接。
2. 加入时间戳与随机数：防止重放攻击（Replay Attack）。
3. 使用密钥计算签名：signature = HMAC-SHA256(secret, string_to_sign)。
4. 放入请求头：通常放在 X-Signature 或 Authorization 头中。

// 签名生成示例（伪代码）
String stringToSign = "GET" + "\n" +
                      "/api/v1/tasks" + "\n" +
                      "page=1&limit=20" + "\n" +
                      "timestamp=1710000000&nonce=abc123";

String signature = hmacSha256("your-secret-key", stringToSign);

// 请求头
X-Timestamp: 1710000000
X-Nonce: abc123
X-Signature: 3a4b5c6d7e8f9g0h...

4.6 四种机制对比与选型建议

4.7 调度平台综合实践建议

• 内部服务间调用：使用 API Key + 签名算法双重保障，密钥定期轮换。
• 第三方集成：采用 OAuth2.0 客户端凭证模式，为每个第三方分配独立的 Client Secret，并限定 Scope。
• 前端用户操作：使用 Bearer Token（JWT），Token 中携带用户 ID 与角色，过期时间不宜过长（建议 30 分钟），配合 Refresh Token 实现无感续期。
• 防重放攻击：所有敏感接口强制要求时间戳 + Nonce 签名校验。
• 日志与审计：记录每次认证请求的来源 IP、API Key 或 Token 标识、操作时间，便于事后追溯。