认证机制：、Bearer 、OAuth 2.0 基础
说实话，我刚开始做 SDK 接入的时候，对认证这事儿挺头疼的。不就是传个密码吗？搞那么多花里胡哨的东西干嘛。后来被坑了几次，才明白这些机制各有各的用处。今天我们就把这三种最常见的认证方式捋清楚。
：最简单的入场券
，说白了就是一个身份标识字符串。你调用接口的时候带上它，服务器就知道你是谁了。
基本用法
// Header 中携带
GET /api/v1/users HTTP/1.1
Host: api.example.com
X-: abc123def456ghi789我个人习惯把 放在请求头里，而不是 URL 参数。为什么？因为 URL 会被日志记录，明晃晃地把 Key 写在那，太不安全了。
使用建议： 适合服务端到服务端的调用，比如你的后端程序去拉取另一个服务的天气数据、汇率信息。不要在客户端（浏览器、手机 App）里硬编码 ，抓包工具一抓就暴露了。
我在项目中遇到的坑
- 有一次我把 写在了前端 JavaScript 代码里，结果上线第二天就被人薅了羊毛。 泄露了，对方拿它疯狂调用付费接口。
- 还有一次，同一个 在多个服务间共享，结果一个服务出问题，所有服务的调用都跟着受影响。
注意： 只是身份标识，不是安全凭证。它通常没有过期时间，泄露了就要手动吊销。建议配合 IP 白名单使用，降低风险。
Bearer ：带授权的令牌
Bearer 比 高级一点。它不光告诉你“我是谁”，还告诉你“我能做什么”。你想想看，饭店里 是会员卡，Bearer 就是带有效期的餐券。
的结构
现在最常用的是 JWT（JSON Web ），它由三部分组成：
- Header：声明类型和加密算法
- Payload：携带用户信息、过期时间等
- Signature：防止篡改的签名
// Bearer 的请求方式
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
// 解析后的 Payload
{
"sub": "user_001",
"role": "admin",
"exp": 1735689600,
"iss": "auth.example.com"
}我见过很多团队直接用 存明文密码，这是个大忌。 虽然被签名了，但 Payload 部分是 Base64 编码，谁都能解码看到内容。我曾经在项目里发现有人把数据库密码放在了 里，当时就惊了。
| 认证方式 | 安全等级 | 适用场景 | 是否可过期 |
|---|---|---|---|
| 低 | 服务间通信、公开 API | 否（需手动吊销） | |
| Bearer | 中 | 用户登录、移动端、单页应用 | 是（JWT 自带过期时间） |
| OAuth 2.0 | 高 | 第三方授权、多系统集成 | 是（支持 refresh_） |
OAuth 2.0：复杂的授权协议
OAuth 2.0 不是简单的认证方式，它是一整套授权框架。说白了，就是解决“我想用你的资源，但我又不想把密码告诉你”这个问题。
核心角色
- 资源所有者：用户自己
- 客户端：你想要接入的 App 或网站
- 授权服务器：颁发 的地方
- 资源服务器：存储用户数据的地方
四种授权模式
- 授权码模式（Authorization Code）：最常用，安全系数最高。用户去授权服务器登录，拿到授权码，再用授权码换 。
- 隐式模式（Implicit）：不用授权码，直接返回 。适合纯前端应用，但现在已经不推荐了。
- 密码模式（Password Credentials）：用户直接把密码给客户端，客户端拿密码去换 。说白了就是代理登录。
- 客户端凭证模式（Client Credentials）：客户端用自己的身份去获取 ，适合服务间调用。
实际项目经验：我做过一个第三方登录 SDK，用的就是授权码模式。用户点了“微信登录”，跳转到微信授权页面，同意后返回授权码，后端再用授权码去微信换 。整个过程用户密码完全不会经过我们的服务器。
我踩过的坑
我记得有一次做 OAuth 2.0 集成，授权码模式下没有校验 redirect_uri，结果被人做了中间人攻击。攻击者伪造了一个授权页面，截获了授权码。从那以后，我对回调 URL 的校验就特别敏感。
重要提醒：OAuth 2.0 本身不保证传输安全，必须配合 HTTPS 使用。还有一个坑是 state 参数，不带上 state 参数容易被 CSRF 攻击。我曾经看到一个项目没加 state，后来被安全团队打回重做。
好了，三种认证机制的核心逻辑就是这个 SVG 图，你们可以对照着理解：