API鉴权为什么重要
没有鉴权的API就像没有门锁的房子——谁都可以进。API鉴权承担着三个核心职责：身份认证（你是谁？）、权限控制（你能做什么？）、调用追踪（你做了什么？）。据OWASP统计，认证失效是API安全的第二大风险。
方案一：API Key / AppSecret
最基础的API认证方式。调用方在请求中携带预先分配的Key和Secret，服务端验证其有效性。优点：实现简单、性能高、适合服务端之间的M2M通信。缺点：Key泄露后难以追溯、无法实现细粒度用户授权、适合「应用级」认证而非「用户级」认证。
方案二：HMAC签名认证
HMAC（Hash-based Message Authentication Code）通过将请求参数+时间戳+密钥进行哈希计算生成签名，服务端使用相同算法验证。即使请求被拦截，攻击者也无法伪造签名（因为不知道密钥）。优点：防止请求篡改和重放攻击。缺点：客户端和服务端都需要实现签名逻辑。
方案三：JWT（JSON Web Token）
JWT是一种自包含的令牌，将用户信息和权限编码在Token中，服务端无需查询数据库即可验证和解析。优点：无状态、支持跨域、适合分布式/微服务架构。缺点：Token签发后无法主动撤销（除非引入黑名单机制）、Payload不可加密（敏感信息不能在JWT中明文传输）。
方案四：OAuth 2.0
OAuth 2.0是当前最完善的授权框架，定义了四种授权模式：授权码模式（Web应用）、隐式模式（单页应用）、密码模式（自家应用）、客户端凭证模式（服务间调用）。优点：授权与认证分离、支持第三方应用授权、行业标准、生态丰富。缺点：实现复杂度最高、需要理解多种授权流程。
四种方案横向对比
| 维度 | API Key | HMAC | JWT | OAuth 2.0 |
|---|---|---|---|---|
| 安全性 | 中 | 高 | 中高 | 高 |
| 实现复杂度 | 低 | 中 | 中 | 高 |
| 性能开销 | 低 | 中 | 低 | 中 |
| 适用场景 | M2M | 金融支付 | Web/微服务 | 对外API平台 |
实战建议：组合使用
在实际项目中，很少有只使用单一方案的。推荐组合：对外API平台——OAuth 2.0（用户授权）+ API Key（应用标识）+ HMAC签名（请求完整性）；内部微服务——JWT（认证传递）+ mTLS（传输安全）；金融/支付API——HMAC签名（防篡改）+ IP白名单（网络层防护）。YesApi Pro内置了以上所有鉴权方式的完整实现，开箱即用。