认证机制：与OAuth 2.0
在对接 Access Audit 接口时，认证是第一步。说白了，就是告诉系统“你是谁，你有没有权限”。
我个人习惯把认证分成两类：轻量级和企业级。今天我们就聊这两种最常见的——和OAuth 2.0。
认证
是最简单的做法。你生成一串字符串，客户端每次请求都带上它。
嗯，像一把共享门禁卡。谁拿到谁就能进。我在项目中见过不少团队直接把密钥写在代码里，结果泄露了……
配置步骤
- 在Access Audit管理后台生成一个（通常是一对 key + secret）。
- 客户端在HTTP请求头中添加
X-: your_key或直接作为查询参数。 - 服务端校验密钥的有效性，匹配则放行，否则返回403。
示例：请求头使用
GET /api/v1/audit/logs HTTP/1.1
Host: audit.example.com
X-: sk_live_abc123def456
Content-Type: application/json优缺点
| 维度 | 说明 |
|---|---|
| 部署成本 | 极低，一行代码就能跑通 |
| 安全等级 | 低，静态密钥容易泄露，无法细粒度控制权限 |
| 适用场景 | 内部工具、短期测试、信任环境 |
| 令牌生命周期 | 永久有效（除非手动吊销） |
⚠ 避坑指南
我曾经接手过一个项目，硬编码在Git仓库里整整三年。建议：
• 密钥永远不要写在代码里，用环境变量或密钥管理服务
• 定期轮换，设置过期策略
• 配合IP白名单使用，限制来源
OAuth 2.0认证
如果你对接的是第三方应用，或者需要控制不同用户的权限，OAuth 2.0是行业标准。它把认证和授权拆开了——你拿到的不是全局钥匙，而是临时通行证。
我偏好用授权码模式（Authorization Code），它最安全。流程看着复杂，但写起代码来其实就那么几步。
核心流程
- 客户端请求授权码：用户浏览器跳转到授权服务器，同意后授权服务器返回一个code。
- 用code换令牌：客户端携带code和client_secret，向授权服务器请求access_和refresh_。
- 使用令牌访问资源：每次请求在Authorization头里带
Bearer <>。 - 刷新令牌：access_过期后，用refresh_获取新令牌，无需用户重新授权。
💡 实战小贴士
我一般在配置时把refresh_的有效期设长一点（比如30天），access_设短（1小时）。这样既安全又减少用户频繁登录的烦恼。
配置要点
- 在Access Audit控制台注册应用，获取 client_id 和 client_secret。
- 设置回调URL（redirect_uri），必须与请求时使用的URI完全一致，否则被拒绝。
- 申请需要的scope，比如
audit:read或audit:write，不要贪多。
示例：cURL使用OAuth 2.0令牌
curl -X GET "https://audit.example.com/api/v1/logs" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6Ik..." \
-H "Accept: application/json"二者对比——选哪个？
| 对比项 | OAuth 2.0 | |
|---|---|---|
| 安全等级 | ⭐ | ⭐⭐⭐⭐ |
| 实施难度 | 1天 | 3～5天（包含授权页开发） |
| 用户粒度 | 无 | 支持（不同用户不同） |
| 令牌可撤销 | 手动 | 自动过期 + 可吊销 |
| 典型场景 | 内部监控脚本 | 第三方集成、移动端、Web应用 |
⚠ 你可能踩过的坑
• 忘加scope导致越权——明明只允许读日志，结果写操作也能执行。
• refresh_不设绑定——一旦泄露，攻击者能长期持有令牌。
• redirect_uri不一致——OAuth服务器直接报错，排查起来挺头疼。
我个人习惯是：对内工具用偷懒，对外暴露的接口一律OAuth 2.0。你可以根据团队规模和风险承受能力灵活选择。嗯，认证这关过了，下一步就是具体配置接口参数了。但那是后面的话题，咱们先把今天这两个机制吃透。