📚 课程目录第3章接口认证方式

接口认证方式：不只是填个参数那么简单

聊到接口调试，有个绕不开的话题——认证。

说白了，服务器得知道你是谁，有没有权限调用这个接口。密钥审计接口更敏感，认证搞错了，数据拿不到，日志也查不了。我见过太多新手卡在这一步了。

四种主流认证方式

常见的接口认证方式，我按使用频率排个序，给你捋一遍。我自己在实际项目里基本都遇到过。

认证方式	原理	安全性	适用场景
Basic Auth	Base64 编码用户名:密码	低（明文传输）	内网调试、临时测试
Bearer	在请求头携带	中（配合 HTTPS）	RESTful API、OAuth2.0
	固定密钥，放在 Header 或参数里	中（易泄露）	开放平台、SDK 接入
摘要认证	挑战-响应，MD5 哈希	高（防重放）	对安全要求高的场景

记住一点：Basic Auth 不要在生产环境裸奔。我曾经在调试一个金融接口时，发现对方直接传明文密码，吓得我赶紧让他们改了。

1. Basic Auth

这是最原始的认证方式。客户端把用户名和密码拼成 username:password，再用 Base64 编码，塞进 Authorization 头里。

举个例子：

GET /api/audit/keys HTTP/1.1
Authorization: Basic YWRtaW46MTIzNDU2

Base64 不是什么加密算法。它只是编码，解码太容易了。所以要是没用 HTTPS，基本等于把密码贴脑门上。

注意：有些工具或老旧系统还默认用 Basic Auth。
我在项目里遇到过对方文档写着"安全认证"，结果一抓包，用户名密码明文可见...嗯，从那以后我再也不信文档了，必须自己抓包看。

2. Bearer

这种方式更灵活。你先登录拿到一个，然后每次请求把它放在 Authorization: Bearer <> 里。

流程是这样的：

客户端发登录请求（用户名、密码）
服务器验证通过，返回一个（通常是 JWT）
后续请求，带上这个就行

举个请求例子：

POST /api/auth/login
{
    "username": "admin",
    "password": "123456"
}

// 返回
{
    "access_": "eyJhbGciOiJIUzI1NiIs..."
}

// 后续请求
GET /api/audit/keys
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

调试小技巧：我习惯在 Postman 的 Pre-request Script 里自动刷新，免得手动复制粘贴。你想想看，每次调试都要重新登录，多烦。

Bearer 比 Basic Auth 强的地方在于：

可以设置过期时间，泄露了影响范围小
支持细粒度权限控制（scopes）
服务端不需要存 session，无状态

3.

这个更直接。服务端给你一个固定密钥，你把它放在请求头或 URL 参数里。

举个例子：

GET /api/audit/keys?=abc123def456

// 或者
GET /api/audit/keys
X-: abc123def456

用法简单，适合开放平台。但问题也明显：

密钥固定，一旦泄露就得换
难以做细粒度控制（谁在什么时间调了什么）

避坑指南：我曾经见过有人把硬编码在 .env 文件里，结果被提交到 GitHub 公开仓库。不到半小时，服务器就被挖矿程序扫了...所以密钥一定要放在环境变量，Git 要加 .gitignore。

4. 摘要认证

这个稍微复杂一点。它不直接传密码，而是用密码参与计算，生成一个哈希值。

流程大致是这样：

客户端请求资源，服务器返回 401，带一个 nonce（一次性随机数）
客户端用 用户名:realm:密码 加上 nonce 等信息，算出一个 MD5
服务器拿同样的信息算一遍，比对哈希值

为什么安全？因为密码本身不会在网络传输。而且有 nonce 防重放攻击。

举个例子（简化版）：

// 服务器返回
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"

// 客户端重新请求
Authorization: Digest username="admin", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/api/audit/keys", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

实战提醒：摘要认证调试起来比较麻烦，因为每次 nonce 都不一样，不好手动模拟。我一般会用 curl --digest 命令，或者让 Postman 自动处理 Digest Auth。

知识体系图

下面这张图把这四种认证方式的关系和流程展示清楚了：

怎么选？我的建议

这四种方式没有的好坏。关键看场景。

Basic Auth：只适合内网快速验证。生产环境别用。
Bearer ：最通用的方案。我大部分项目都用这个。
：给第三方用最方便。但要做好密钥管理和监控。
摘要认证：老派但安全。适合对安全有硬性要求的场景。

我个人习惯：调试密钥审计接口时，我通常会先用 Bearer 过一遍流程，确认通了再用目标系统要求的认证方式。原因很简单—— 调试工具支持最好，Postman、cURL 都原生支持，省心。

你想想看，一个接口调试半天，最后发现是认证方式选错了，多冤枉。把这四种方式摸透了，以后遇到任何接口认证都不会慌。