06身份验证

API 身份验证是确保 API 访问者身份合法性的机制，通过验证客户端的身份信息，确保只有授权的请求能访问受保护的资源。

## 一、基本身份验证

基本身份验证 - Basic Authentication

定义：一种简单的 HTTP 身份验证方式，通过用户名和密码的组合验证客户端身份。

> 工作原理

客户端将用户名和密码用冒号拼接（如username:password），再通过 Base64 编码生成一个字符串；

请求时在 HTTP 头中添加Authorization: Basic <编码后的字符串>；

服务器解码后验证用户名和密码是否匹配。

> 优缺点

优点：实现简单，无需复杂的令牌管理；

缺点：Base64 编码是可逆的（非加密），明文传输存在安全风险（必须配合 HTTPS 使用）；每次请求都需携带凭证，不适合频繁交互。

> 示例

假设用户名为alice，密码为pass123，拼接后为alice:pass123，Base64 编码后为YWxpY2U6cGFzczEyMw==。

```http
GET /api/data HTTP/1.1
Host: example.com
Authorization: Basic YWxpY2U6cGFzczEyMw==
```

## 二、API密钥（API Key）

定义：服务器为客户端分配的唯一字符串（密钥），客户端通过在请求中携带密钥证明身份。

> 工作原理

客户端向服务器申请 API 密钥（通常通过开发者平台手动创建）；

请求时将密钥放在指定位置（如请求头、查询参数、请求体）；

服务器验证密钥是否存在且有效（如未过期、未被吊销）。

> 常见携带位置

请求头（推荐）：如X-API-Key: <密钥>；

查询参数：如 `https://example.com/api/data?api_key=`<密钥>（不推荐，易泄露）；

请求体（仅适用于 POST/PUT 等方法）。

> 优缺点

优点：实现简单，适合服务器到服务器的通信（如第三方服务调用）；

缺点：密钥是静态的，一旦泄露需手动吊销并重新生成；无法区分用户角色（仅验证客户端身份，不涉及用户权限）。

> 示例

假设 API 密钥为sk_8f7d2b9e-4a1c-5d3e-8b7f-1234567890ab，通过请求头携带：

```http
GET /api/weather HTTP/1.1
Host: weather-api.com
X-API-Key: sk_8f7d2b9e-4a1c-5d3e-8b7f-1234567890ab
```

## 三、JWT（JSON Web Token）

定义：一种基于 JSON 的轻量级令牌（Token），用于在客户端和服务器间安全传递声明（如用户身份、权限），支持无状态验证。

> 工作原理

生成：客户端通过用户名密码等凭证向认证服务器请求令牌，服务器验证后生成 JWT（包含三部分：头部 Header、载荷 Payload、签名 Signature）：

- Header：指定令牌类型（JWT）和签名算法（如 HS256）；
- Payload：存储用户 ID、过期时间（exp）等非敏感信息（不加密，仅 Base64 编码）；
- Signature：用服务器密钥对 Header 和 Payload 的编码结果签名（防止篡改）。

使用：客户端在请求头中携带Authorization: Bearer \<JWT>；

验证：服务器验证签名是否有效（确保未被篡改），并检查过期时间等声明。

调试器：`https://www.jwt.io/`

> 优缺点

优点：无状态（服务器无需存储令牌，适合分布式系统）；支持携带用户权限信息，减少数据库查询；

缺点：令牌一旦生成无法主动吊销（除非设置短期过期或维护黑名单）；Payload 未加密，不可存储敏感信息。

> 示例

一个 JWT 令牌格式（三部分用.分隔）：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsIm5hbWUiOiJBbGljZSIsImV4cCI6MTcxODAwMDAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

请求头格式：

```http
GET /api/user/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsIm5hbWUiOiJBbGljZSIsImV4cCI6MTcxODAwMDAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

## 四、HMAC

HMAC（Hash-based Message Authentication Code）

定义：基于哈希的消息认证码，通过客户端和服务器共享的密钥对请求内容（如 URL、参数、时间戳）生成哈希值，验证请求的完整性和身份。

> 工作原理

客户端和服务器预先约定密钥（仅双方知晓）和哈希算法（如 SHA256）；

客户端生成请求时，将请求的关键信息（如请求方法、URL、参数、时间戳）拼接成字符串，用密钥和算法生成 HMAC 值；

请求中携带 HMAC 值和原始信息（如时间戳）；

服务器用相同的密钥和信息重新计算 HMAC，对比是否与客户端发送的一致（同时验证时间戳防止重放攻击）。

> 优缺点

优点：安全性高（密钥不传输，哈希值不可逆向破解）；能防止请求被篡改和重放攻击；

缺点：实现复杂（需处理参数排序、时间戳同步等）；不适合简单场景。

> 示例

假设请求信息为：

- 方法：GET
- URL：/api/orders
- 参数：id=123&status=paid
- 时间戳：1620000000
- 密钥：secret_key

客户端计算步骤：

1. 拼接字符串：GET&/api/orders&id=123&status=paid&1620000000
2. 用 SHA256 和密钥secret_key生成 HMAC 值：a1b2c3d4e5f6...

请求头携带 HMAC 和时间戳：

```http
GET /api/orders?id=123&status=paid HTTP/1.1
Host: example.com
X-HMAC-Signature: a1b2c3d4e5f6...
X-Timestamp: 1620000000
```

## 五、OAuth 2.0

定义：一种授权框架（非直接身份验证），允许第三方应用在用户授权下访问用户在资源服务器上的受保护资源（如 “用微信登录”）。

> 核心角色

资源所有者（用户）：授权第三方访问自己的资源；

客户端（第三方应用）：请求访问资源的应用；

授权服务器：验证用户身份并发放令牌；

资源服务器：存储用户资源，验证令牌并响应请求。

>常见授权流程（以最常用的 “授权码流程” 为例）：

客户端引导用户到授权服务器，请求授权（如 `https://auth.example.com/authorize?client_id=xxx&redirect_uri=xxx&response_type=code`）；

用户登录并同意授权，授权服务器返回授权码（code）；

客户端用授权码向授权服务器换取访问令牌（access_token）；

客户端携带访问令牌访问资源服务器（如Authorization: Bearer <access_token>）；

资源服务器验证令牌有效后返回资源。

> 优缺点

优点：灵活支持多种授权场景（如第三方登录、权限细分）；令牌可限制有效期和权限范围；

缺点：实现复杂（需处理多种流程和令牌管理）；依赖 HTTPS 保障安全。

> 示例

假设 “第三方应用 A” 需访问用户在 “资源服务器 B” 的相册：

用户在 A 中点击 “授权访问 B 的相册”，跳转至 B 的授权页；

用户登录 B 并同意授权，B 返回授权码code=abc123；

A 用code=abc123向 B 的授权服务器请求令牌：

```http
POST /oauth/token HTTP/1.1
Host: auth.b.com
Content-Type: application/x-www-form-urlencoded

client_id=appA_id&client_secret=appA_secret&code=abc123&grant_type=authorization_code&redirect_uri=https://appA.com/callback

```

授权服务器返回令牌：

```http
{
  "access_token": "at_7f9d2b3c-1a4e-5f6d-8b7c-1234567890ab",
  "token_type": "bearer",
  "expires_in": 3600
}
```

A用令牌返回资源：

```http
GET /api/photos HTTP/1.1
Host: resource.b.com
Authorization: Bearer at_7f9d2b3c-1a4e-5f6d-8b7c-1234567890ab
```

## 六、无身份验证

无身份验证 - No Authentication

定义：API 完全公开，无需任何身份验证即可访问。

适用场景：公开的、无敏感信息的资源（如公开的天气数据、公共新闻 API）。

优缺点：

- 优点：实现最简单，适合高频访问的公开资源；
- 缺点：无安全性，易被滥用（如恶意请求攻击）。

示例：
一个公开的天气 API，直接请求即可返回数据：

```http
GET /api/public/weather?city=beijing HTTP/1.1
Host: public-weather-api.com
```