API 认证要解决的核心问题是：调用方（应用或用户）怎么向你的 API 证明「我有资格访问」。三者的出发点不同：API Key 证明「这是哪个应用」；HTTP Basic Auth 证明「这是哪个用户/应用的账号密码」；OAuth 2.0 证明「用户已授权这个应用以特定范围访问」。下面逐个拆解。
做 API 安全时，第一件事就是决定「应用和用户怎么证明自己」。本文编译自 Nordic APIs（2020-06-23，作者 Daniel Lindau，2023-11-16 更新），把三种最常见做法——API Key、HTTP Basic Auth、OAuth 2.0——摆在一起对比，讲清各自的用法、优缺点，以及「什么时候该用哪个」。
API 认证要解决的核心问题是：调用方（应用或用户）怎么向你的 API 证明「我有资格访问」。三者的出发点不同：API Key 证明「这是哪个应用」；HTTP Basic Auth 证明「这是哪个用户/应用的账号密码」；OAuth 2.0 证明「用户已授权这个应用以特定范围访问」。下面逐个拆解。
API Key 是一种只识别应用、不关联具体用户的认证方式：应用把 key 加进每个请求，API 用它识别来源应用并做限流、统计等。Key 放哪各家不同——有的放 query 参数，有的放自定义头，有的放 body。例如 Google Cloud 把 key 放 query：
curl -X POST https://language.googleapis.com/v1/documents:analyzeEntities?key=API_KEYCloudflare 则要求放自定义头：
curl https://api.cloudflare.com/client/v4/zones/cd7d0123e301230df9514d \
-H "X-Auth-Key:1234567893feefc5f0q5000bfo0c38d90bbeb" \
-H "X-Auth-Email:example@example.com"优点：客户端用起来简单，加个 key 就行。缺点：Key 只认应用不认人；难以保密——URL 会进日志、JS 代码几乎是明文、移动 App 易被反编译；且 Key 没有统一标准，每家实现都不同。结论：Key 只能用于「标识客户端做统计/限流」，不能当成安全基石。
Basic Auth 是经典的「账号+密码」式认证：把 username:password 做 base64 后塞进 Authorization 头。例如用户 daniel / password：
GET / HTTP/1.1
Host: example.com
Authorization: Basic ZGFuaWVsOnBhc3N3b3Jk它通常每个请求都带这个头，实质上变成了一个静态字符串（类似 API Key）。优点：标准化、实现简单，适合服务器间（server-to-server）内部环境。缺点：一旦用于认证用户，应用就必须收集用户密码——用户不知道 App 拿密码干啥，且撤回权限的唯一办法是改密码；密码是长期令牌，泄露后难察觉；无法做多因子认证（MFA）。如今 Basic Auth 已基本被视为遗留方案。
OAuth 2.0（RFC 6749）是当下最主流的令牌协议：由可信的授权服务器（AS）发令牌，服务凭令牌放行。举个经典例子——用户 Alice 想让第三方画图App读取她家温度服务的数据：
https://as.temperatures.com/authorize?client_id=third_party_graphs&scope=read_temperatures；AS 在浏览器里认证 Alice（可用 MFA），并询问「是否允许该 App 读温度」；Alice 同意后，AS 签发令牌回给 App。App 之后用令牌调用：Authorization: Bearer <token>。令牌有两种形态：引用令牌（reference token）需 AS 做 introspection 校验（返回 active/sub/client_id/scope 等声明）；JWT 则可被服务用 AS 公钥直接验签，无需回查。OAuth 的好处肉眼可见：凭证只给可信站点、可用 MFA、用户可撤回授权而不改密码、可细粒度授权、声明随请求直达、全程标准化。
| 方式 | 适合场景 | 不适合 |
|---|---|---|
| HTTP Basic Auth | 内部网络简单验证、开放数据加一道校验 | 任何面向公网、涉敏的场景（已近淘汰） |
| API Key | 认证「应用」、做限流/统计/计费标识、变现型开放 API | 作为唯一安全手段；含 PII 或需认用户时 |
| OAuth 2.0 | 零信任环境、大量 PII、第三方代访、需 MFA 与可撤回授权 | 极简内部脚本（成本偏高） |
OAuth 2.0 诞生于 API 市场爆发的时代，API Key 与 Basic Auth 的大部分用例它都已覆盖，在各方面都更胜一筹。小而特定的场景用 Key/Basic 尚可，但凡打算成长壮大的系统，都应转向基于令牌的架构（如 Neo Security Architecture）。本文只讲了用户流，OAuth 还有多种服务端到服务端（server-to-server）的令牌获取流程值得深入。