1. 快速阅读1.1. 为什么需要认证没有认证的世界任何人 ──请求──▶ 服务器 ──返回──▶ 所有人的数据 ❌有认证的世界陌生人 ──请求──▶ 服务器 ──▶ 你是谁没有凭证拒绝 ✅合法用户 ──请求凭证──▶ 服务器 ──▶ 验证通过返回数据 ✅1.2 认证方式总览认证方式总览HTTP 认证方式 ├── Basic Auth 用户名密码最古老 ├── Bearer Token 令牌认证最常见 │ └── JWT 自包含令牌 ├── API Key 开放平台常用 ├── OAuth 2.0 第三方授权 ├── Session/Cookie 浏览器场景 └── HMAC 签名 高安全场景各认证方式的格式对比方式格式Basic AuthAuthorization:Basicbase64(user:pwd)Bearer TokenAuthorization:BearertokenJWTAuthorization:Bearerjwt类型tokenAPI KeyX-API-Key: key或 URL参数?api_keykeyOAuth 2.0Authorization:Beareraccess_tokenSession / Cookie自动携带Cookie: sidsessionIdHMAC 签名X-Signature: hmac签名值附带X-Timestamp: 时间戳安全性对比方式安全性复杂度适用场景Basic Auth⭐⭐⭐内网/测试Bearer Token⭐⭐⭐⭐⭐通用APIJWT⭐⭐⭐⭐⭐分布式系统API Key⭐⭐⭐⭐开放平台OAuth 2.0⭐⭐⭐⭐⭐⭐⭐⭐⭐第三方登录Session/Cookie⭐⭐⭐⭐⭐传统WebHMAC 签名⭐⭐⭐⭐⭐⭐⭐⭐⭐金融/支付2. HTTP认证方式介绍2.1 Basic Auth基础认证原理把 用户名:密码 用 Base64 编码后放进请求头格式用户名: admin 密码: 123456 ↓ Base64 编码 Authorization: Basic YWRtaW46MTIzNDU2 │ │ │ │ │ └─ admin:123456 编码后字符串 │ └─ 固定关键字表示认证类型 └─ HTTP 标准请求头流程客户端 服务器 │ │ │ GET /api/data │ │ Authorization: Basic xxx │ │ ────────────────────────────▶ │ │ │ Base64解码 │ │ 得到 admin:123456 │ │ 查库验证 │ 返回数据 │ │ ◀──────────────────────────── │⚠️ 缺点Base64 不是加密 YWRtaW46MTIzNDU2 可以直接解码得到 admin:123456 所以 ❌ 不用 HTTPS 的话密码完全裸奔 ❌ 每次请求都要带密码泄露风险高 ❌ 无法设置过期时间 ❌ 现代项目基本不用适用场景✅ 内网简单工具 ✅ 快速原型开发 ✅ 测试环境2.2 Bearer Token令牌认证原理用户登录后服务器发一个令牌 之后每次请求带上这个令牌而不是带密码格式Authorization: Bearer token值 │ │ │ │ │ └─ 你的 Token 字符串 │ └─ 固定关键字表示认证类型 └─ HTTP 标准请求头 # 实际例子 #1. Token为随机字符串 # ·简单的随机字符串 # ·服务器存储对应关系 # ·不含任何信息纯粹当钥匙用 Authorization: Bearer secret_abc123xyzABCXYZ456 #2.JWTJSON Web Token # .Token 本身包含用户信息 # .服务器无需查库直接解码验证 # .常用于登录场景 Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.abc123 │ │ │ Header(算法) Payload(数据) Signature(签名)流程客户端 服务器 │ POST /login │ │ { user: admin, pwd: 123} │ │ ────────────────────────────▶ │ │ │ 验证密码 │ 返回 Token │ 生成 Token │ { token: abc123... } │ 存储 Token │ ◀──────────────────────────── │ │ │ │ GET /api/data │ │ Authorization: Bearer abc123 │ │ ────────────────────────────▶ │ │ │ 查库验证 Token │ 返回数据 │ │ ◀──────────────────────────── │服务器验证token流程收到请求 │ ▼ 提取 Authorization Header 中的 Token │ ▼ 查库这个 Token 存在吗 │ ├─── 不存在 → 返回 401 Unauthorized │ ▼ Token 过期了吗 │ ├─── 过期 → 返回 401 Unauthorized │ ▼ 该 Token 有权限访问这个资源吗 │ ├─── 无权限 → 返回 403 Forbidden │ ▼ ✅ 验证通过返回数据优缺点✅ 不用每次传密码 ✅ 可以设置过期时间 ✅ 可以随时撤销删库中的Token ❌ 服务器需要存储Token有状态 ❌ Token泄露后持有者即可访问2.3 JWTJSON Web Token原理一种特殊的 Bearer Token Token 本身包含用户信息 服务器不需要查库直接解码验证格式Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36P │ │ │ Header(算法) Payload(数据) Signature(签名)JWT的结构eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36P └─────────────────┘ └─────────────────┘ └──────────────────────────┘ Header Payload Signature 算法信息 用户数据 关键防篡改Signature 签名是如何生成的Signature HMAC_SHA256( Base64(Header) . Base64(Payload), 服务器密钥(SECRET_KEY) ← 只有服务器知道 ) 【SECRET_KEY】相关知识 1.SECRET_KEY是服务器自己配置的通常只有一个只有服务器自己知道(类似防伪印章) 2.SECRET_KEY 通常写在服务器的配置文件或环境变量中JWT_SECRET_KEYmy_super_secret_key_123 3.即使黑客修改了Payload但不知道 SECRET_KEY 无法修改Signature最后会生成的 jwt token不能通过服务器的验证// Header 解码后 { alg: HS256, // 签名算法 typ: JWT } // Payload 解码后 { userId: 123, username: admin, role: user, exp: 1716239022 // 过期时间 } // Signature用密钥对前两部分签名防止篡改流程客户端 服务器 │ POST /login │ │ ────────────────────────────▶ │ │ │ 验证密码 │ 返回 JWT Token │ 生成JWT不存库 │ ◀──────────────────────────── │ │ │ │ GET /api/data │ │ Authorization: Bearer JWT │ │ ────────────────────────────▶ │ │ │ 解码JWT │ │ 验证签名是否合法 │ │ 检查是否过期 │ 返回数据 │ 无需查库 │ ◀──────────────────────────── │验证JWT流程收到 JWT │ ▼ 拆分三段 │ ▼ 用 SECRET_KEY 对 HeaderPayload 重新计算签名 │ ├─── 签名不一致 ──▶ ❌ Token 被篡改拒绝 │ ▼ 解码 Payload检查 exp 过期时间 │ ├─── 已过期 ──▶ ❌ Token 过期拒绝 │ ▼ ✅ 验证通过 从 Payload 中取出用户信息直接使用 无需查库具体例子step1.服务器生成 jwt tokenHeader Payload 内容 eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30 服务器密钥 my_super_secret_key_123 ↓ 经过 HMAC_SHA256 运算 生成签名 SflKxwRJSMeKKF2QT4fwpMeJf36Pstep2.服务器验证JWT tokeneyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30.SflKxwRJSMeKKF2QT4fwpMeJf36Pstep2.1 拆分 TokenHeader: eyJhbGciOiJIUzI1NiJ9 Payload: eyJ1c2VySWQiOjEyM30 Signature: SflKxwRJSMeKKF2QT4fwpMeJf36P ← 用户带来的签名step2.2 服务器自己重新计算签名用自己存储的 SECRET_KEY 对 Header Payload 重新运算一次 HMAC_SHA256( eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEyM30, my_super_secret_key_123 ) ↓ 得到SflKxwRJSMeKKF2QT4fwpMeJf36P ← 服务器计算出的签名step2.3 对比两个签名用户带来的签名SflKxwRJSMeKKF2QT4fwpMeJf36P 服务器计算的签名SflKxwRJSMeKKF2QT4fwpMeJf36P ↓ 两者相同 ✅ 验证通过Token 合法优缺点✅ 服务器无需存储无状态 ✅ 适合分布式系统多台服务器都能验证 ✅ 可携带用户信息减少查库 ❌ Token 无法主动撤销只能等过期 ❌ Payload 只是 Base64 编码不要存敏感信息 ❌ Token 越大每次请求的体积越大Bearer Token vs JWTBearer Token ← JWT 是 Bearer Token 的一种实现 普通 Bearer Token 是随机字符串 JWT 是包含信息的结构化字符串 就像 交通工具 ← 汽车是交通工具的一种2.4 API Key接口密钥原理平台给你分配一个固定的密钥 每次请求带上这个密钥格式多种携带方式# 方式1放在 Header X-API-Key: sk-abc123xyz # 方式2放在 URL 参数 GET /api/data?api_keysk-abc123xyz # 方式3放在 Authorization Header Authorization: Api-Key sk-abc123xyz实际例子# OpenAI API Authorization: Bearer sk-proj-abc123... # 高德地图 GET /maps?keyabc123... # 自定义Header X-API-Key: your-key-here优缺点✅ 简单直接容易接入 ✅ 适合服务器之间调用 ✅ 可以针对不同Key设置不同权限 ❌ 放在URL中有泄露风险会被记录在日志里 ❌ 长期有效泄露风险较高 ❌ 不适合浏览器端直接使用适用场景✅ 开放平台地图、天气、支付 ✅ 服务器间的 API 调用 ✅ 第三方服务集成Notion、OpenAI2.5 OAuth 2.0第三方授权原理不是直接认证你是谁 而是你授权我访问你在某平台的数据流程最常见的使用微信登录场景为例用户 你的App 微信服务器 │ │ │ │ 点击 │ │ │ 微信登录 │ │ │ ──────────▶ │ │ │ │ 跳转到微信 │ │ │ ─────────────▶ │ │ │ │ │ 微信询问授权给该App │ │ ◀─────────────────────────── │ │ │ │ │ 点击确认 │ │ │ ──────────────────────────▶ │ │ │ │ 生成授权码 │ │ 返回授权码 │ │ │ ◀───────────── │ │ │ │ │ │ 用授权码换Token │ │ │ ─────────────▶ │ │ │ 返回Token │ │ │ ◀───────────── │ │ │ │ │ │ 用Token获取 │ │ │ 用户信息 │ │ │ ─────────────▶ │ │ 登录成功 │ 返回用户信息 │ │ ◀────────── │ ◀───────────── │优缺点✅ 不需要把密码给第三方 ✅ 可以精细控制授权范围只读/读写 ✅ 可以随时撤销授权 ❌ 流程复杂实现成本高 ❌ 对小项目来说过于繁重2.6 Session / Cookie会话认证原理登录后服务器生成 Session 把 Session ID 存入 Cookie 浏览器自动携带 Cookie 发请求流程浏览器 服务器 │ POST /login │ │ { user, password } │ │ ────────────────────────────▶ │ │ │ 验证密码 │ │ 创建 Session │ │ 存储 Session 信息 │ Set-Cookie: sidabc123 │ │ ◀──────────────────────────── │ │ │ │ GET /dashboard │ │ Cookie: sidabc123 自动 │ │ ────────────────────────────▶ │ │ │ 根据sid查Session │ 返回页面 │ 获取用户信息 │ ◀──────────────────────────── │优缺点✅ 浏览器自动管理开发简单 ✅ 服务器可以主动让Session失效 ✅ 传统Web应用的标配 ❌ 服务器需要存储所有Session有状态 ❌ 分布式部署时需要共享Session存储 ❌ 有 CSRF 攻击风险 ❌ 不适合 App / 小程序没有Cookie机制2.7 HMAC 签名认证原理不传密码而是用密码对请求内容进行签名 服务器用同样的方式验证签名流程请求参数 时间戳 密钥 │ ▼ HMAC 算法 │ 签名值 发送请求参数 时间戳 签名值不含密钥实际例子AWS 风格GET /api/data X-Timestamp: 1716239022 X-Signature: HMAC-SHA256(请求内容 时间戳, 密钥)优缺点✅ 密钥永远不在网络上传输 ✅ 防止请求被篡改 ✅ 时间戳防止重放攻击 ❌ 实现复杂 ❌ 客户端和服务器时间需要同步适用场景✅ 金融、支付场景微信支付、支付宝 ✅ 高安全要求的 API ✅ AWS、阿里云等云服务 API