←Discover

HTTP 请求有哪些常见的鉴权方式？

HTTP 请求有哪些常见的鉴权方式？

HTTP 请求有哪些常见的鉴权方式？

HTTP 请求有哪些常见的鉴权方式？

在 Web 开发、接口设计和微服务通信中，“鉴权”几乎是绕不开的话题。所谓 HTTP 请求鉴权，就是服务端用某种方式确认“你是谁”以及“你有没有权限访问这个资源”。

很多初学者容易把认证和授权混为一谈：

  • 认证（Authentication）：确认身份，你是不是你声称的那个用户
  • 授权（Authorization）：确认权限，你能不能访问这个资源

本文重点介绍 HTTP 请求中常见的鉴权方式、适用场景、优缺点，以及实际开发中的选择建议。

为什么 HTTP 需要鉴权？

HTTP 本身是无状态协议，单次请求天然不会记住“上一次是谁来过”。因此，如果没有额外机制，服务端无法知道：

  • 当前请求来自谁
  • 请求是否被伪造
  • 调用者是否有访问权限
  • 请求是否被篡改或重放

所以，鉴权机制通常要解决以下几个问题：

  • 身份识别：确认调用者身份
  • 权限控制：限制资源访问范围
  • 完整性校验：避免请求内容被篡改
  • 防重放攻击：防止旧请求被重复利用
  • 安全传输：配合 HTTPS 防止凭证泄露

常见 HTTP 鉴权方式总览

下面先看一个概览表。

鉴权方式典型位置是否无状态常见场景主要特点
Cookie + SessionCookie / 服务端 Session否传统 Web 网站服务端保存登录态
Basic AuthAuthorization 头是简单接口、内部系统用户名密码 Base64 编码
Bearer TokenAuthorization 头是前后端分离、移动端常见、实现简单
JWTAuthorization 头是微服务、SSO、APIToken 自包含信息
API KeyHeader / Query是Open API、服务调用简单直接
HMAC 签名Header + 签名串是高安全 API、支付接口可防篡改、防重放
OAuth 2.0多种头和跳转流程通常是第三方授权登录、开放平台面向授权委托
mTLSTLS 层证书是企业内网、B2B、高安全环境双向证书认证

1. Cookie + Session

这是传统 Web 应用最经典的方案。

工作原理

  1. 用户登录，提交用户名和密码
  2. 服务端验证成功后创建 Session
  3. 服务端把 Session ID 返回给浏览器，通常放在 Cookie 中
  4. 浏览器后续请求自动带上 Cookie
  5. 服务端根据 Session ID 查找登录状态

流程示意

优点

  • 实现成熟，框架支持完善
  • 适合服务端渲染页面应用
  • 服务端易于主动失效会话

缺点

  • 服务端要保存 Session，扩展性一般
  • 分布式部署时要考虑 Session 共享或粘性会话
  • 容易受到 CSRF 攻击，需要配合防护

适用场景

  • 传统网站后台
  • 管理系统
  • 服务端渲染应用

2. Basic Auth

Basic Auth 是 HTTP 标准中非常基础的一种认证方式。

工作原理

客户端把用户名和密码拼接后进行 Base64 编码，放到 Authorization 请求头中：

http
Authorization: Basic dXNlcjpwYXNzd29yZA==

其中 dXNlcjpwYXNzd29yZA== 实际上是 user:password 的 Base64 编码。

示例代码

bash
curl -u user:password https://api.example.com/data

优点

  • 非常简单
  • 各种 HTTP 客户端天然支持
  • 适合快速测试或内部工具

缺点

  • Base64 不是加密，只是编码
  • 用户名密码会在每次请求中发送
  • 必须强制配合 HTTPS 使用

适用场景

  • 内部测试接口
  • 简单后台服务
  • 临时性认证需求

3. Bearer Token

Bearer Token 是现代 API 最常见的方式之一。

工作原理

用户登录成功后，服务端签发一个 token，客户端后续请求带上：

http
Authorization: Bearer <token>

服务端验证 token 是否有效、是否过期、对应用户是谁。

示例

http
GET /api/profile HTTP/1.1Host: api.example.comAuthorization: Bearer abcdef123456

优点

  • 简单清晰，适合前后端分离
  • 服务端可以做成无状态
  • 移动端、SPA、小程序都很适合

缺点

  • Token 泄露后，持有者即可使用
  • 需要处理过期、刷新、吊销机制
  • 如果保存在浏览器不当位置，可能有 XSS 风险

适用场景

  • 前后端分离项目
  • App 接口
  • 微服务网关后的用户请求

4. JWT（JSON Web Token）

JWT 是 Bearer Token 的一种常见实现形式。它本质上是一个自包含的令牌。

JWT 结构

JWT 通常由三部分组成：

  • Header
  • Payload
  • Signature

格式如下：

text
xxxxx.yyyyy.zzzzz

可以简单理解为：

text
+------------+------------+-------------+|   Header   |  Payload   |  Signature  |+------------+------------+-------------+

典型内容

Payload 中常见字段：

  • sub：用户标识
  • exp：过期时间
  • iat：签发时间
  • iss：签发者
  • roles：角色信息

优点

  • 无状态，服务端不必存储会话
  • 可跨服务传递用户信息
  • 适合分布式系统和微服务

缺点

  • 一旦签发，吊销不方便
  • Payload 只是 Base64URL 编码，不是加密
  • Token 太长时会增加请求体积
  • 不适合存放敏感信息

适用场景

  • 单点登录（SSO）
  • 微服务内部身份传递
  • 前后端分离认证

JWT 示例代码

javascript
const jwt = require('jsonwebtoken');
const token = jwt.sign(  { sub: 'user_123', roles: ['admin'] },  'secret-key',  { expiresIn: '1h' });
console.log(token);

5. API Key

API Key 常用于开放平台接口或服务间调用。

工作原理

平台给调用方分配一个唯一密钥，请求时携带：

http
X-API-Key: your_api_key_here

有些系统也会放在 query 参数中，但不太推荐：

http
GET /data?api_key=xxxx

优点

  • 非常简单
  • 易于发放和管理
  • 适合识别“调用方应用”而不是最终用户

缺点

  • 单独使用时安全性一般
  • 容易泄露在日志、浏览器历史或 URL 中
  • 通常只能标识应用，不能证明请求未被篡改

适用场景

  • Open API
  • 内部服务识别
  • 第三方开发者接入

6. HMAC 签名鉴权

这是一种更安全的 API 鉴权方式，常见于支付、云服务、对象存储等场景。

工作原理

客户端和服务端共享一个密钥，客户端把请求方法、路径、时间戳、请求参数等按规则拼接成字符串，再用 HMAC 算法计算签名。

服务端收到请求后，按同样规则重新计算签名并比对。

简化示例

假设签名原文为：

text
GET/api/ordertimestamp=1710000000user_id=1001

然后计算：

signature=HMAC(secret,stringToSign)signature = HMAC(secret, stringToSign)

请求头可能像这样：

http
X-Access-Key: ak_123X-Timestamp: 1710000000X-Signature: abcdefxyz

优点

  • 可以校验请求是否被篡改
  • 可结合时间戳、nonce 防重放攻击
  • 不直接传输明文密码

缺点

  • 实现复杂度较高
  • 前后端签名规则必须完全一致
  • 调试成本高

适用场景

  • 支付接口
  • 云服务 API
  • 高安全要求的服务调用

7. OAuth 2.0

OAuth 2.0 严格来说不是“单一鉴权方法”，而是授权框架。它解决的是：用户如何允许第三方应用访问自己的资源，而不直接暴露密码。

常见角色

  • Resource Owner：用户
  • Client：第三方应用
  • Authorization Server：授权服务器
  • Resource Server：资源服务器

常见流程

最常见的是 Authorization Code 模式：

优点

  • 不必把用户密码交给第三方应用
  • 适合开放平台和第三方登录
  • 权限范围可细粒度控制

缺点

  • 概念多、流程复杂
  • 实现门槛高于普通 token
  • 容易和“登录”概念混淆

适用场景

  • 微信/Google/GitHub 登录
  • 开放平台授权
  • 第三方访问用户资源

8. mTLS（双向 TLS）

mTLS 是在传输层进行双向证书认证。除了服务端向客户端证明身份，客户端也要出示证书给服务端验证。

优点

  • 安全性很高
  • 适合机器到机器通信
  • 证书级别的身份确认更可靠

缺点

  • 证书发放、更新、吊销管理复杂
  • 不适合普通浏览器用户场景
  • 运维成本较高

适用场景

  • 企业内网服务调用
  • 金融系统
  • B2B 系统对接
  • Service Mesh

如何选择合适的鉴权方式？

可以参考下面这张表。

场景推荐方式
传统网站登录Cookie + Session
前后端分离接口Bearer Token / JWT
第三方开放 APIAPI Key + 签名
第三方登录OAuth 2.0
高安全服务间调用HMAC 签名 / mTLS
简单内部接口Basic Auth（需 HTTPS）

一个实用的选择原则

  • 给浏览器用户做登录态：优先考虑 Cookie + Session
  • 给移动端或 SPA 做认证：优先考虑 Bearer Token / JWT
  • 给第三方开发者开放接口：API Key 通常不够，建议加签名
  • 给服务到服务通信：考虑 JWT、HMAC、mTLS
  • 涉及用户授权给第三方：使用 OAuth 2.0

实战中的安全建议

无论使用哪种鉴权方式，都建议遵循这些原则：

  • 必须使用 HTTPS
  • Token 设置过期时间
  • 敏感操作增加二次校验
  • 避免把密钥放到 URL 参数
  • 防止重放攻击：时间戳 + nonce
  • 做好权限分级，不只校验“是否登录”
  • 服务端记录审计日志
  • 妥善保管密钥和证书
  • 防范 XSS、CSRF、暴力破解

总结

HTTP 请求的常见鉴权方式各有侧重：

  • Cookie + Session：适合传统 Web
  • Basic Auth：简单但基础
  • Bearer Token：现代 API 常用
  • JWT：适合分布式和微服务
  • API Key：适合开放接口的调用方识别
  • HMAC 签名：安全性更高，适合关键接口
  • OAuth 2.0：解决第三方授权问题
  • mTLS：适合高安全机器通信

实际系统里，经常不是只用一种，而是组合使用。例如：

  • OAuth 2.0 + Bearer Token
  • API Key + HMAC 签名
  • HTTPS + JWT + RBAC 权限控制
  • mTLS + 服务网关鉴权

如果你在设计 API，最重要的不是“选最流行的”，而是根据业务场景、安全要求、系统复杂度、运维能力来做平衡。