3、API认证与授权：API Key认证、OAuth 2.0流程、JWT令牌机制、基本认证与摘要认证
说到API安全，我第一个想聊的就是认证与授权。这两个词经常被混用，但本质完全不同。认证是「你是谁」，授权是「你能干什么」。很多新手在这上面栽过跟头，包括我自己。
我记得刚入行那会儿，给一个内部系统写接口，觉得「反正别人也不知道这个地址」，连认证都没加。结果被老大哥骂了一顿。嗯，从那以后，我再也不敢偷懒了。
今天咱们就把四种主流的认证方式掰开揉碎讲清楚。你想想看，搞懂了这些，以后对接任何第三方API都不会慌。
3.1 API Key认证：最简单也最容易被滥用
API Key，说白了就是一个字符串。你把它放在请求头里，服务端校验一下，通过就放行。简单粗暴。
核心逻辑：服务端生成一个唯一标识（Key），客户端每次请求都带上它。
我在项目中遇到过不少团队直接把API Key写在URL里：
GET /api/users?api_key=abc123def456这种做法我强烈不建议。为什么呢？URL会被浏览器历史、服务器日志、反向代理记录下来，等于把钥匙扔在大街上。
正确的做法是放在请求头里：
GET /api/users
Authorization: Bearer abc123def456避坑指南：我曾经见过一个项目，API Key直接硬编码在前端代码里。用户打开控制台就能看到。这等于把家门钥匙挂在门外。API Key只适合服务端到服务端的通信，千万别用在浏览器端。
3.2 基本认证与摘要认证：老牌选手
基本认证（Basic Auth）是HTTP协议自带的认证方式。原理很简单：把用户名和密码用Base64编码一下，塞进请求头。
Authorization: Basic dXNlcjpwYXNz注意，Base64不是加密，是编码。随便找个在线工具就能解码。所以基本认证必须搭配HTTPS使用，否则等于裸奔。
摘要认证（Digest Auth）比基本认证稍微聪明一点。它不会直接传输密码，而是用MD5对密码加一个随机数（nonce）做哈希。就算被截获，攻击者也拿不到原始密码。
我个人习惯是：内部调试用基本认证，生产环境基本不用这两种方式。太老了，安全性也跟不上。现在主流方案是OAuth 2.0和JWT。
3.3 OAuth 2.0流程：授权界的标准答案
OAuth 2.0不是一种认证协议，而是一种授权框架。它解决的核心问题是：如何让第三方应用安全地访问用户资源，而不需要暴露用户的密码。
举个例子：你用微信登录某个网站。网站不会知道你的微信密码，微信只给它一个临时令牌。这就是OAuth 2.0的典型场景。
OAuth 2.0有四种授权模式，我挑最常用的两种讲：
| 模式 | 适用场景 | 安全性 |
|---|---|---|
| 授权码模式 | 有后端的Web应用 | 高 |
| 客户端凭证模式 | 服务端到服务端 | 中 |
授权码模式的流程大概是这样的：
- 用户点击「微信登录」，跳转到微信授权页面
- 用户同意授权，微信返回一个临时授权码
- 后端拿着授权码去微信换令牌（Access Token）
- 后续请求都带上这个令牌
这里有个关键点：授权码只在后端交换，前端拿不到。这就避免了令牌泄露的风险。
个人经验：我建议你在实现OAuth 2.0时，一定要校验redirect_uri。曾经有个项目因为没校验这个参数，被攻击者利用开放重定向漏洞窃取了授权码。血的教训。
3.4 JWT令牌机制：无状态认证的利器
JWT（JSON Web Token）是目前最流行的令牌格式。它把用户信息编码到令牌本身，服务端不需要查数据库就能验证身份。
一个JWT长这样：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c它由三部分组成：Header（头部）、Payload（载荷）、Signature（签名）。用点号分隔。
Payload里可以放用户ID、角色、过期时间等。但千万别放密码、信用卡号这类敏感信息。因为Payload只是Base64编码，不是加密的。
JWT最大的优势是无状态。服务端不需要存session，直接解析令牌就能知道用户是谁。这在微服务架构下特别有用。
避坑指南：我曾经遇到过一个问题：JWT签发时不设置过期时间。结果令牌泄露后，攻击者可以永久使用。记住，JWT一定要设置exp（过期时间）字段，而且不要太长。一般15分钟到1小时比较合理。
3.5 四种认证方式对比
说了这么多，咱们用一张表总结一下：
| 认证方式 | 安全性 | 复杂度 | 适用场景 |
|---|---|---|---|
| API Key | 低 | 低 | 服务端到服务端 |
| 基本认证 | 低（需HTTPS） | 极低 | 调试、内部工具 |
| 摘要认证 | 中 | 中 | 遗留系统 |
| OAuth 2.0 | 高 | 高 | 第三方授权、开放平台 |
| JWT | 中高 | 中 | 无状态认证、微服务 |
你想想看，没有一种认证方式是万能的。API Key简单但脆弱，OAuth 2.0安全但复杂。关键是根据场景选对工具。
3.6 核心知识体系
下面这张图展示了本章的知识脉络，我手绘了一个SVG，帮你理清思路：
嗯，这张图把四种认证方式的关系和要点都串起来了。你可以把它当作一个快速参考。
3.7 实战建议
最后，我结合自己的踩坑经验，给你几条实在的建议：
- 能用OAuth 2.0就别自己造轮子。 我见过太多团队自己写认证逻辑，结果漏洞百出。
- JWT的签名密钥要定期轮换。 密钥泄露等于所有令牌都失效。
- API Key要支持吊销。 万一泄露了，能立刻让Key失效。
- 所有认证方式都必须配合HTTPS。 这是底线，没得商量。
一个小技巧：我在项目中习惯把认证逻辑封装成一个中间件。这样每个接口只需要加一行注解或配置，就能启用认证。既统一又方便维护。
好了，认证与授权这块就聊到这儿。记住一句话：安全不是功能，而是一种习惯。养成好习惯，比什么都重要。
公众号:蓝海资料掘金营，微信deep3321