{"schemaVersion":"drillso.agent.session.v1","scope":"node","resource":{"type":"shared-session","shareId":"2Mj_dE2alX5B","title":"HTTP 请求有哪些常见的鉴权方式？","canonicalUrl":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/http-%E8%AF%B7%E6%B1%82%E6%9C%89%E5%93%AA%E4%BA%9B%E5%B8%B8%E8%A7%81%E7%9A%84%E9%89%B4%E6%9D%83%E6%96%B9%E5%BC%8F%EF%BC%9F-10d6c728","agentUrl":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/agent.json?node=http-%E8%AF%B7%E6%B1%82%E6%9C%89%E5%93%AA%E4%BA%9B%E5%B8%B8%E8%A7%81%E7%9A%84%E9%89%B4%E6%9D%83%E6%96%B9%E5%BC%8F%EF%BC%9F-10d6c728","ownerName":"pyth0nb3st","updatedAt":"2026-04-29T12:30:15.135Z"},"currentNode":{"id":"10d6c728-79fd-425c-a138-2121933446c2","slug":"http-请求有哪些常见的鉴权方式？-10d6c728","title":"HTTP 请求有哪些常见的鉴权方式？","type":"page","url":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/http-%E8%AF%B7%E6%B1%82%E6%9C%89%E5%93%AA%E4%BA%9B%E5%B8%B8%E8%A7%81%E7%9A%84%E9%89%B4%E6%9D%83%E6%96%B9%E5%BC%8F%EF%BC%9F-10d6c728","agentUrl":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/agent.json?node=http-%E8%AF%B7%E6%B1%82%E6%9C%89%E5%93%AA%E4%BA%9B%E5%B8%B8%E8%A7%81%E7%9A%84%E9%89%B4%E6%9D%83%E6%96%B9%E5%BC%8F%EF%BC%9F-10d6c728","text":"## HTTP 请求有哪些常见的鉴权方式？\n\n在 Web 开发、接口设计和微服务通信中，“鉴权”几乎是绕不开的话题。所谓 HTTP 请求鉴权，就是服务端用某种方式确认“你是谁”以及“你有没有权限访问这个资源”。\n\n很多初学者容易把**认证**和**授权**混为一谈：\n\n- **认证（Authentication）**：确认身份，你是不是你声称的那个用户\n- **授权（Authorization）**：确认权限，你能不能访问这个资源\n\n本文重点介绍 HTTP 请求中常见的鉴权方式、适用场景、优缺点，以及实际开发中的选择建议。\n\n---\n\n## 为什么 HTTP 需要鉴权？\n\nHTTP 本身是**无状态协议**，单次请求天然不会记住“上一次是谁来过”。因此，如果没有额外机制，服务端无法知道：\n\n- 当前请求来自谁\n- 请求是否被伪造\n- 调用者是否有访问权限\n- 请求是否被篡改或重放\n\n所以，鉴权机制通常要解决以下几个问题：\n\n- **身份识别**：确认调用者身份\n- **权限控制**：限制资源访问范围\n- **完整性校验**：避免请求内容被篡改\n- **防重放攻击**：防止旧请求被重复利用\n- **安全传输**：配合 HTTPS 防止凭证泄露\n\n---\n\n## 常见 HTTP 鉴权方式总览\n\n下面先看一个概览表。\n\n| 鉴权方式 | 典型位置 | 是否无状态 | 常见场景 | 主要特点 |\n|---|---|---:|---|---|\n| Cookie + Session | Cookie / 服务端 Session | 否 | 传统 Web 网站 | 服务端保存登录态 |\n| Basic Auth | `Authorization` 头 | 是 | 简单接口、内部系统 | 用户名密码 Base64 编码 |\n| Bearer Token | `Authorization` 头 | 是 | 前后端分离、移动端 | 常见、实现简单 |\n| JWT | `Authorization` 头 | 是 | 微服务、SSO、API | Token 自包含信息 |\n| API Key | Header / Query | 是 | Open API、服务调用 | 简单直接 |\n| HMAC 签名 | Header + 签名串 | 是 | 高安全 API、支付接口 | 可防篡改、防重放 |\n| OAuth 2.0 | 多种头和跳转流程 | 通常是 | 第三方授权登录、开放平台 | 面向授权委托 |\n| mTLS | TLS 层证书 | 是 | 企业内网、B2B、高安全环境 | 双向证书认证 |\n\n---\n\n## 1. Cookie + Session\n\n这是传统 Web 应用最经典的方案。\n\n### 工作原理\n\n1. 用户登录，提交用户名和密码\n2. 服务端验证成功后创建 Session\n3. 服务端把 Session ID 返回给浏览器，通常放在 Cookie 中\n4. 浏览器后续请求自动带上 Cookie\n5. 服务端根据 Session ID 查找登录状态\n\n### 流程示意\n\n```mermaid\nflowchart LR\n    A[\"用户登录\"] --> B[\"服务端校验账号密码\"]\n    B --> C[\"创建 Session\"]\n    C --> D[\"Set-Cookie: session_id=xxx\"]\n    D --> E[\"浏览器保存 Cookie\"]\n    E --> F[\"后续请求自动携带 Cookie\"]\n    F --> G[\"服务端根据 session_id 查登录态\"]\n```\n\n### 优点\n\n- 实现成熟，框架支持完善\n- 适合服务端渲染页面应用\n- 服务端易于主动失效会话\n\n### 缺点\n\n- 服务端要保存 Session，扩展性一般\n- 分布式部署时要考虑 Session 共享或粘性会话\n- 容易受到 CSRF 攻击，需要配合防护\n\n### 适用场景\n\n- 传统网站后台\n- 管理系统\n- 服务端渲染应用\n\n---\n\n## 2. Basic Auth\n\nBasic Auth 是 HTTP 标准中非常基础的一种认证方式。\n\n### 工作原理\n\n客户端把用户名和密码拼接后进行 Base64 编码，放到 `Authorization` 请求头中：\n\n```http\nAuthorization: Basic dXNlcjpwYXNzd29yZA==\n```\n\n其中 `dXNlcjpwYXNzd29yZA==` 实际上是 `user:password` 的 Base64 编码。\n\n### 示例代码\n\n```bash\ncurl -u user:password https://api.example.com/data\n```\n\n### 优点\n\n- 非常简单\n- 各种 HTTP 客户端天然支持\n- 适合快速测试或内部工具\n\n### 缺点\n\n- Base64 不是加密，只是编码\n- 用户名密码会在每次请求中发送\n- 必须强制配合 HTTPS 使用\n\n### 适用场景\n\n- 内部测试接口\n- 简单后台服务\n- 临时性认证需求\n\n---\n\n## 3. Bearer Token\n\nBearer Token 是现代 API 最常见的方式之一。\n\n### 工作原理\n\n用户登录成功后，服务端签发一个 token，客户端后续请求带上：\n\n```http\nAuthorization: Bearer <token>\n```\n\n服务端验证 token 是否有效、是否过期、对应用户是谁。\n\n### 示例\n\n```http\nGET /api/profile HTTP/1.1\nHost: api.example.com\nAuthorization: Bearer abcdef123456\n```\n\n### 优点\n\n- 简单清晰，适合前后端分离\n- 服务端可以做成无状态\n- 移动端、SPA、小程序都很适合\n\n### 缺点\n\n- Token 泄露后，持有者即可使用\n- 需要处理过期、刷新、吊销机制\n- 如果保存在浏览器不当位置，可能有 XSS 风险\n\n### 适用场景\n\n- 前后端分离项目\n- App 接口\n- 微服务网关后的用户请求\n\n---\n\n## 4. JWT（JSON Web Token）\n\nJWT 是 Bearer Token 的一种常见实现形式。它本质上是一个自包含的令牌。\n\n### JWT 结构\n\nJWT 通常由三部分组成：\n\n- Header\n- Payload\n- Signature\n\n格式如下：\n\n```text\nxxxxx.yyyyy.zzzzz\n```\n\n可以简单理解为：\n\n```text\n+------------+------------+-------------+\n|   Header   |  Payload   |  Signature  |\n+------------+------------+-------------+\n```\n\n### 典型内容\n\nPayload 中常见字段：\n\n- `sub`：用户标识\n- `exp`：过期时间\n- `iat`：签发时间\n- `iss`：签发者\n- `roles`：角色信息\n\n### 优点\n\n- 无状态，服务端不必存储会话\n- 可跨服务传递用户信息\n- 适合分布式系统和微服务\n\n### 缺点\n\n- 一旦签发，吊销不方便\n- Payload 只是 Base64URL 编码，不是加密\n- Token 太长时会增加请求体积\n- 不适合存放敏感信息\n\n### 适用场景\n\n- 单点登录（SSO）\n- 微服务内部身份传递\n- 前后端分离认证\n\n### JWT 示例代码\n\n```javascript\nconst jwt = require('jsonwebtoken');\n\nconst token = jwt.sign(\n  { sub: 'user_123', roles: ['admin'] },\n  'secret-key',\n  { expiresIn: '1h' }\n);\n\nconsole.log(token);\n```\n\n---\n\n## 5. API Key\n\nAPI Key 常用于开放平台接口或服务间调用。\n\n### 工作原理\n\n平台给调用方分配一个唯一密钥，请求时携带：\n\n```http\nX-API-Key: your_api_key_here\n```\n\n有些系统也会放在 query 参数中，但不太推荐：\n\n```http\nGET /data?api_key=xxxx\n```\n\n### 优点\n\n- 非常简单\n- 易于发放和管理\n- 适合识别“调用方应用”而不是最终用户\n\n### 缺点\n\n- 单独使用时安全性一般\n- 容易泄露在日志、浏览器历史或 URL 中\n- 通常只能标识应用，不能证明请求未被篡改\n\n### 适用场景\n\n- Open API\n- 内部服务识别\n- 第三方开发者接入\n\n---\n\n## 6. HMAC 签名鉴权\n\n这是一种更安全的 API 鉴权方式，常见于支付、云服务、对象存储等场景。\n\n### 工作原理\n\n客户端和服务端共享一个密钥，客户端把请求方法、路径、时间戳、请求参数等按规则拼接成字符串，再用 HMAC 算法计算签名。\n\n服务端收到请求后，按同样规则重新计算签名并比对。\n\n### 简化示例\n\n假设签名原文为：\n\n```text\nGET\n/api/order\ntimestamp=1710000000\nuser_id=1001\n```\n\n然后计算：\n\n$$\nsignature = HMAC(secret, stringToSign)\n$$\n\n请求头可能像这样：\n\n```http\nX-Access-Key: ak_123\nX-Timestamp: 1710000000\nX-Signature: abcdefxyz\n```\n\n### 优点\n\n- 可以校验请求是否被篡改\n- 可结合时间戳、nonce 防重放攻击\n- 不直接传输明文密码\n\n### 缺点\n\n- 实现复杂度较高\n- 前后端签名规则必须完全一致\n- 调试成本高\n\n### 适用场景\n\n- 支付接口\n- 云服务 API\n- 高安全要求的服务调用\n\n---\n\n## 7. OAuth 2.0\n\nOAuth 2.0 严格来说不是“单一鉴权方法”，而是**授权框架**。它解决的是：用户如何允许第三方应用访问自己的资源，而不直接暴露密码。\n\n### 常见角色\n\n- **Resource Owner**：用户\n- **Client**：第三方应用\n- **Authorization Server**：授权服务器\n- **Resource Server**：资源服务器\n\n### 常见流程\n\n最常见的是 **Authorization Code** 模式：\n\n```mermaid\nsequenceDiagram\n    participant U as 用户\n    participant C as 第三方应用\n    participant A as 授权服务器\n    participant R as 资源服务器\n\n    U->>C: 点击第三方登录\n    C->>A: 跳转授权页面\n    A->>U: 用户登录并同意授权\n    A->>C: 返回授权码 code\n    C->>A: 用 code 换 access token\n    A->>C: 返回 access token\n    C->>R: 携带 token 请求资源\n    R->>C: 返回受保护数据\n```\n\n### 优点\n\n- 不必把用户密码交给第三方应用\n- 适合开放平台和第三方登录\n- 权限范围可细粒度控制\n\n### 缺点\n\n- 概念多、流程复杂\n- 实现门槛高于普通 token\n- 容易和“登录”概念混淆\n\n### 适用场景\n\n- 微信/Google/GitHub 登录\n- 开放平台授权\n- 第三方访问用户资源\n\n---\n\n## 8. mTLS（双向 TLS）\n\nmTLS 是在传输层进行双向证书认证。除了服务端向客户端证明身份，客户端也要出示证书给服务端验证。\n\n### 优点\n\n- 安全性很高\n- 适合机器到机器通信\n- 证书级别的身份确认更可靠\n\n### 缺点\n\n- 证书发放、更新、吊销管理复杂\n- 不适合普通浏览器用户场景\n- 运维成本较高\n\n### 适用场景\n\n- 企业内网服务调用\n- 金融系统\n- B2B 系统对接\n- Service Mesh\n\n---\n\n## 如何选择合适的鉴权方式？\n\n可以参考下面这张表。\n\n| 场景 | 推荐方式 |\n|---|---|\n| 传统网站登录 | Cookie + Session |\n| 前后端分离接口 | Bearer Token / JWT |\n| 第三方开放 API | API Key + 签名 |\n| 第三方登录 | OAuth 2.0 |\n| 高安全服务间调用 | HMAC 签名 / mTLS |\n| 简单内部接口 | Basic Auth（需 HTTPS） |\n\n### 一个实用的选择原则\n\n- **给浏览器用户做登录态**：优先考虑 Cookie + Session\n- **给移动端或 SPA 做认证**：优先考虑 Bearer Token / JWT\n- **给第三方开发者开放接口**：API Key 通常不够，建议加签名\n- **给服务到服务通信**：考虑 JWT、HMAC、mTLS\n- **涉及用户授权给第三方**：使用 OAuth 2.0\n\n---\n\n## 实战中的安全建议\n\n无论使用哪种鉴权方式，都建议遵循这些原则：\n\n- **必须使用 HTTPS**\n- **Token 设置过期时间**\n- **敏感操作增加二次校验**\n- **避免把密钥放到 URL 参数**\n- **防止重放攻击：时间戳 + nonce**\n- **做好权限分级，不只校验“是否登录”**\n- **服务端记录审计日志**\n- **妥善保管密钥和证书**\n- **防范 XSS、CSRF、暴力破解**\n\n---\n\n## 总结\n\nHTTP 请求的常见鉴权方式各有侧重：\n\n- **Cookie + Session**：适合传统 Web\n- **Basic Auth**：简单但基础\n- **Bearer Token**：现代 API 常用\n- **JWT**：适合分布式和微服务\n- **API Key**：适合开放接口的调用方识别\n- **HMAC 签名**：安全性更高，适合关键接口\n- **OAuth 2.0**：解决第三方授权问题\n- **mTLS**：适合高安全机器通信\n\n实际系统里，经常不是只用一种，而是**组合使用**。例如：\n\n- `OAuth 2.0 + Bearer Token`\n- `API Key + HMAC 签名`\n- `HTTPS + JWT + RBAC 权限控制`\n- `mTLS + 服务网关鉴权`\n\n如果你在设计 API，最重要的不是“选最流行的”，而是根据**业务场景、安全要求、系统复杂度、运维能力**来做平衡。","markdown":"## HTTP 请求有哪些常见的鉴权方式？\n\n在 Web 开发、接口设计和微服务通信中，“鉴权”几乎是绕不开的话题。所谓 HTTP 请求鉴权，就是服务端用某种方式确认“你是谁”以及“你有没有权限访问这个资源”。\n\n很多初学者容易把**认证**和**授权**混为一谈：\n\n- **认证（Authentication）**：确认身份，你是不是你声称的那个用户\n- **授权（Authorization）**：确认权限，你能不能访问这个资源\n\n本文重点介绍 HTTP 请求中常见的鉴权方式、适用场景、优缺点，以及实际开发中的选择建议。\n\n---\n\n## 为什么 HTTP 需要鉴权？\n\nHTTP 本身是**无状态协议**，单次请求天然不会记住“上一次是谁来过”。因此，如果没有额外机制，服务端无法知道：\n\n- 当前请求来自谁\n- 请求是否被伪造\n- 调用者是否有访问权限\n- 请求是否被篡改或重放\n\n所以，鉴权机制通常要解决以下几个问题：\n\n- **身份识别**：确认调用者身份\n- **权限控制**：限制资源访问范围\n- **完整性校验**：避免请求内容被篡改\n- **防重放攻击**：防止旧请求被重复利用\n- **安全传输**：配合 HTTPS 防止凭证泄露\n\n---\n\n## 常见 HTTP 鉴权方式总览\n\n下面先看一个概览表。\n\n| 鉴权方式 | 典型位置 | 是否无状态 | 常见场景 | 主要特点 |\n|---|---|---:|---|---|\n| Cookie + Session | Cookie / 服务端 Session | 否 | 传统 Web 网站 | 服务端保存登录态 |\n| Basic Auth | `Authorization` 头 | 是 | 简单接口、内部系统 | 用户名密码 Base64 编码 |\n| Bearer Token | `Authorization` 头 | 是 | 前后端分离、移动端 | 常见、实现简单 |\n| JWT | `Authorization` 头 | 是 | 微服务、SSO、API | Token 自包含信息 |\n| API Key | Header / Query | 是 | Open API、服务调用 | 简单直接 |\n| HMAC 签名 | Header + 签名串 | 是 | 高安全 API、支付接口 | 可防篡改、防重放 |\n| OAuth 2.0 | 多种头和跳转流程 | 通常是 | 第三方授权登录、开放平台 | 面向授权委托 |\n| mTLS | TLS 层证书 | 是 | 企业内网、B2B、高安全环境 | 双向证书认证 |\n\n---\n\n## 1. Cookie + Session\n\n这是传统 Web 应用最经典的方案。\n\n### 工作原理\n\n1. 用户登录，提交用户名和密码\n2. 服务端验证成功后创建 Session\n3. 服务端把 Session ID 返回给浏览器，通常放在 Cookie 中\n4. 浏览器后续请求自动带上 Cookie\n5. 服务端根据 Session ID 查找登录状态\n\n### 流程示意\n\n```mermaid\nflowchart LR\n    A[\"用户登录\"] --> B[\"服务端校验账号密码\"]\n    B --> C[\"创建 Session\"]\n    C --> D[\"Set-Cookie: session_id=xxx\"]\n    D --> E[\"浏览器保存 Cookie\"]\n    E --> F[\"后续请求自动携带 Cookie\"]\n    F --> G[\"服务端根据 session_id 查登录态\"]\n```\n\n### 优点\n\n- 实现成熟，框架支持完善\n- 适合服务端渲染页面应用\n- 服务端易于主动失效会话\n\n### 缺点\n\n- 服务端要保存 Session，扩展性一般\n- 分布式部署时要考虑 Session 共享或粘性会话\n- 容易受到 CSRF 攻击，需要配合防护\n\n### 适用场景\n\n- 传统网站后台\n- 管理系统\n- 服务端渲染应用\n\n---\n\n## 2. Basic Auth\n\nBasic Auth 是 HTTP 标准中非常基础的一种认证方式。\n\n### 工作原理\n\n客户端把用户名和密码拼接后进行 Base64 编码，放到 `Authorization` 请求头中：\n\n```http\nAuthorization: Basic dXNlcjpwYXNzd29yZA==\n```\n\n其中 `dXNlcjpwYXNzd29yZA==` 实际上是 `user:password` 的 Base64 编码。\n\n### 示例代码\n\n```bash\ncurl -u user:password https://api.example.com/data\n```\n\n### 优点\n\n- 非常简单\n- 各种 HTTP 客户端天然支持\n- 适合快速测试或内部工具\n\n### 缺点\n\n- Base64 不是加密，只是编码\n- 用户名密码会在每次请求中发送\n- 必须强制配合 HTTPS 使用\n\n### 适用场景\n\n- 内部测试接口\n- 简单后台服务\n- 临时性认证需求\n\n---\n\n## 3. Bearer Token\n\nBearer Token 是现代 API 最常见的方式之一。\n\n### 工作原理\n\n用户登录成功后，服务端签发一个 token，客户端后续请求带上：\n\n```http\nAuthorization: Bearer <token>\n```\n\n服务端验证 token 是否有效、是否过期、对应用户是谁。\n\n### 示例\n\n```http\nGET /api/profile HTTP/1.1\nHost: api.example.com\nAuthorization: Bearer abcdef123456\n```\n\n### 优点\n\n- 简单清晰，适合前后端分离\n- 服务端可以做成无状态\n- 移动端、SPA、小程序都很适合\n\n### 缺点\n\n- Token 泄露后，持有者即可使用\n- 需要处理过期、刷新、吊销机制\n- 如果保存在浏览器不当位置，可能有 XSS 风险\n\n### 适用场景\n\n- 前后端分离项目\n- App 接口\n- 微服务网关后的用户请求\n\n---\n\n## 4. JWT（JSON Web Token）\n\nJWT 是 Bearer Token 的一种常见实现形式。它本质上是一个自包含的令牌。\n\n### JWT 结构\n\nJWT 通常由三部分组成：\n\n- Header\n- Payload\n- Signature\n\n格式如下：\n\n```text\nxxxxx.yyyyy.zzzzz\n```\n\n可以简单理解为：\n\n```text\n+------------+------------+-------------+\n|   Header   |  Payload   |  Signature  |\n+------------+------------+-------------+\n```\n\n### 典型内容\n\nPayload 中常见字段：\n\n- `sub`：用户标识\n- `exp`：过期时间\n- `iat`：签发时间\n- `iss`：签发者\n- `roles`：角色信息\n\n### 优点\n\n- 无状态，服务端不必存储会话\n- 可跨服务传递用户信息\n- 适合分布式系统和微服务\n\n### 缺点\n\n- 一旦签发，吊销不方便\n- Payload 只是 Base64URL 编码，不是加密\n- Token 太长时会增加请求体积\n- 不适合存放敏感信息\n\n### 适用场景\n\n- 单点登录（SSO）\n- 微服务内部身份传递\n- 前后端分离认证\n\n### JWT 示例代码\n\n```javascript\nconst jwt = require('jsonwebtoken');\n\nconst token = jwt.sign(\n  { sub: 'user_123', roles: ['admin'] },\n  'secret-key',\n  { expiresIn: '1h' }\n);\n\nconsole.log(token);\n```\n\n---\n\n## 5. API Key\n\nAPI Key 常用于开放平台接口或服务间调用。\n\n### 工作原理\n\n平台给调用方分配一个唯一密钥，请求时携带：\n\n```http\nX-API-Key: your_api_key_here\n```\n\n有些系统也会放在 query 参数中，但不太推荐：\n\n```http\nGET /data?api_key=xxxx\n```\n\n### 优点\n\n- 非常简单\n- 易于发放和管理\n- 适合识别“调用方应用”而不是最终用户\n\n### 缺点\n\n- 单独使用时安全性一般\n- 容易泄露在日志、浏览器历史或 URL 中\n- 通常只能标识应用，不能证明请求未被篡改\n\n### 适用场景\n\n- Open API\n- 内部服务识别\n- 第三方开发者接入\n\n---\n\n## 6. HMAC 签名鉴权\n\n这是一种更安全的 API 鉴权方式，常见于支付、云服务、对象存储等场景。\n\n### 工作原理\n\n客户端和服务端共享一个密钥，客户端把请求方法、路径、时间戳、请求参数等按规则拼接成字符串，再用 HMAC 算法计算签名。\n\n服务端收到请求后，按同样规则重新计算签名并比对。\n\n### 简化示例\n\n假设签名原文为：\n\n```text\nGET\n/api/order\ntimestamp=1710000000\nuser_id=1001\n```\n\n然后计算：\n\n$$\nsignature = HMAC(secret, stringToSign)\n$$\n\n请求头可能像这样：\n\n```http\nX-Access-Key: ak_123\nX-Timestamp: 1710000000\nX-Signature: abcdefxyz\n```\n\n### 优点\n\n- 可以校验请求是否被篡改\n- 可结合时间戳、nonce 防重放攻击\n- 不直接传输明文密码\n\n### 缺点\n\n- 实现复杂度较高\n- 前后端签名规则必须完全一致\n- 调试成本高\n\n### 适用场景\n\n- 支付接口\n- 云服务 API\n- 高安全要求的服务调用\n\n---\n\n## 7. OAuth 2.0\n\nOAuth 2.0 严格来说不是“单一鉴权方法”，而是**授权框架**。它解决的是：用户如何允许第三方应用访问自己的资源，而不直接暴露密码。\n\n### 常见角色\n\n- **Resource Owner**：用户\n- **Client**：第三方应用\n- **Authorization Server**：授权服务器\n- **Resource Server**：资源服务器\n\n### 常见流程\n\n最常见的是 **Authorization Code** 模式：\n\n```mermaid\nsequenceDiagram\n    participant U as 用户\n    participant C as 第三方应用\n    participant A as 授权服务器\n    participant R as 资源服务器\n\n    U->>C: 点击第三方登录\n    C->>A: 跳转授权页面\n    A->>U: 用户登录并同意授权\n    A->>C: 返回授权码 code\n    C->>A: 用 code 换 access token\n    A->>C: 返回 access token\n    C->>R: 携带 token 请求资源\n    R->>C: 返回受保护数据\n```\n\n### 优点\n\n- 不必把用户密码交给第三方应用\n- 适合开放平台和第三方登录\n- 权限范围可细粒度控制\n\n### 缺点\n\n- 概念多、流程复杂\n- 实现门槛高于普通 token\n- 容易和“登录”概念混淆\n\n### 适用场景\n\n- 微信/Google/GitHub 登录\n- 开放平台授权\n- 第三方访问用户资源\n\n---\n\n## 8. mTLS（双向 TLS）\n\nmTLS 是在传输层进行双向证书认证。除了服务端向客户端证明身份，客户端也要出示证书给服务端验证。\n\n### 优点\n\n- 安全性很高\n- 适合机器到机器通信\n- 证书级别的身份确认更可靠\n\n### 缺点\n\n- 证书发放、更新、吊销管理复杂\n- 不适合普通浏览器用户场景\n- 运维成本较高\n\n### 适用场景\n\n- 企业内网服务调用\n- 金融系统\n- B2B 系统对接\n- Service Mesh\n\n---\n\n## 如何选择合适的鉴权方式？\n\n可以参考下面这张表。\n\n| 场景 | 推荐方式 |\n|---|---|\n| 传统网站登录 | Cookie + Session |\n| 前后端分离接口 | Bearer Token / JWT |\n| 第三方开放 API | API Key + 签名 |\n| 第三方登录 | OAuth 2.0 |\n| 高安全服务间调用 | HMAC 签名 / mTLS |\n| 简单内部接口 | Basic Auth（需 HTTPS） |\n\n### 一个实用的选择原则\n\n- **给浏览器用户做登录态**：优先考虑 Cookie + Session\n- **给移动端或 SPA 做认证**：优先考虑 Bearer Token / JWT\n- **给第三方开发者开放接口**：API Key 通常不够，建议加签名\n- **给服务到服务通信**：考虑 JWT、HMAC、mTLS\n- **涉及用户授权给第三方**：使用 OAuth 2.0\n\n---\n\n## 实战中的安全建议\n\n无论使用哪种鉴权方式，都建议遵循这些原则：\n\n- **必须使用 HTTPS**\n- **Token 设置过期时间**\n- **敏感操作增加二次校验**\n- **避免把密钥放到 URL 参数**\n- **防止重放攻击：时间戳 + nonce**\n- **做好权限分级，不只校验“是否登录”**\n- **服务端记录审计日志**\n- **妥善保管密钥和证书**\n- **防范 XSS、CSRF、暴力破解**\n\n---\n\n## 总结\n\nHTTP 请求的常见鉴权方式各有侧重：\n\n- **Cookie + Session**：适合传统 Web\n- **Basic Auth**：简单但基础\n- **Bearer Token**：现代 API 常用\n- **JWT**：适合分布式和微服务\n- **API Key**：适合开放接口的调用方识别\n- **HMAC 签名**：安全性更高，适合关键接口\n- **OAuth 2.0**：解决第三方授权问题\n- **mTLS**：适合高安全机器通信\n\n实际系统里，经常不是只用一种，而是**组合使用**。例如：\n\n- `OAuth 2.0 + Bearer Token`\n- `API Key + HMAC 签名`\n- `HTTPS + JWT + RBAC 权限控制`\n- `mTLS + 服务网关鉴权`\n\n如果你在设计 API，最重要的不是“选最流行的”，而是根据**业务场景、安全要求、系统复杂度、运维能力**来做平衡。","structured":null,"children":[{"id":"8d2468b4-507d-4d51-8409-0c6220f0cfa9","slug":"http-8d2468b4","title":"HTTP","type":"summary","url":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/http-8d2468b4","agentUrl":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/agent.json?node=http-8d2468b4"}]},"breadcrumbs":[],"parent":null,"children":[{"id":"8d2468b4-507d-4d51-8409-0c6220f0cfa9","slug":"http-8d2468b4","title":"HTTP","type":"summary","url":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/http-8d2468b4","agentUrl":"https://drillso.com/en/share/sessions/2Mj_dE2alX5B/agent.json?node=http-8d2468b4"}],"fullTree":null,"warnings":[],"truncated":false}