OAuth 2.0：服务间调用与授权模式
OAuth 2.0 是一套开放授权框架，用于让客户端在不直接获取资源所有者密码的情况下，获得访问受保护资源的有限权限。
1. OAuth 2.0 是什么
OAuth 2.0 主要解决的是“授权”，不是完整的用户登录协议。常见实现会结合 JWT、OpenID Connect 或其他身份系统完成认证。
它解决的核心问题是：
客户端如何在不接触用户密码的情况下
获得访问受保护资源的有限权限2. 四个核心角色
| 角色 | 含义 |
|---|---|
| 资源所有者 Resource Owner | 对受保护资源拥有授权决定权的主体，通常是用户 |
| 客户端 Client | 请求访问资源的应用，可以是前端、移动端或后端服务 |
| 授权服务器 Authorization Server | 负责验证客户端或用户身份，并签发 access token |
| 资源服务器 Resource Server | 保存受保护资源，并验证 access token 后提供 API |
授权服务器和资源服务器可以是两个独立服务，也可以由同一个系统承担。
3. Client Credentials 模式
Client Credentials Grant 适合后端服务之间的调用：
没有用户参与
客户端使用自己的身份申请 token基本流程：
客户端持有 client_id + client_secret
↓
POST /oauth/token
grant_type=client_credentials
↓
授权服务器验证客户端凭证
↓
返回 access_token 和 expires_in
↓
客户端请求业务 API
Authorization: Bearer <access_token>
↓
资源服务器验证 token 并返回资源请求示例：
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=...&client_secret=...访问资源示例：
GET /api/protected-resource
Authorization: Bearer <access_token>这个模式表达的是：
应用访问应用资源不是：
某个用户登录后访问自己的资源4. 为什么要缓存 access token
access token 通常有有效期。客户端不应该每次调用业务接口前都重新申请 token，而应该：
- 保存 token 和过期时间；
- 在有效期内复用 token；
- 在提前一段时间，例如提前 5～10 分钟刷新；
- 收到 token 失效响应时重新申请并重试一次。
这样可以减少授权服务器压力，也避免业务请求因频繁换 token 变慢。
5. scope 的作用
scope 表示客户端请求或被授予的权限范围，例如：
read:users
write:orders它解决的是：
客户端可以访问哪些资源
或者
客户端可以执行哪些操作因此要区分：
认证：你是谁？
授权：你能做什么？有效 token 只说明客户端通过了身份验证。
资源服务器仍然可以根据 scope、角色、资源归属和业务规则拒绝请求。
6. access token、JWT 与 OAuth 2.0 的关系
三者不是同一个概念：
| 概念 | 作用 |
|---|---|
| OAuth 2.0 | 授权框架，规定角色、流程和 token 使用方式 |
| access token | 客户端访问资源时携带的凭证 |
| JWT | 一种 token 的数据格式和签名方式 |
access token 可以是 JWT，也可以是不透明的随机字符串。
使用 JWT 时，资源服务器可以通过签名、过期时间和声明验证 token。
使用不透明 token 时，通常需要向授权服务器或数据库查询其状态。
7. 常见授权模式
授权码模式 Authorization Code
适合用户参与的 Web 或移动应用授权：
用户登录并同意授权
↓
客户端获得 authorization code
↓
客户端用 code 换 access_token常见参数包括：
response_type=code
client_id
redirect_uri
scope
state现代 Web 应用通常还会使用 PKCE。
客户端凭证模式 Client Credentials
适合后端服务调用后端服务：
- 不需要用户登录；
- 不需要跳转；
- 是服务间 API 调用的重点模式。
密码模式 Resource Owner Password Credentials
客户端直接提交用户名和密码换 token。
它会扩大客户端接触用户密码的范围，已经不适合新系统，通常只在遗留系统兼容场景中出现。
隐式模式 Implicit
早期为浏览器前端设计，直接返回 token。
由于 token 暴露和安全控制问题，现代新系统通常不再推荐使用。
8. OAuth 2.0 与 Casbin 的区别
OAuth 2.0 主要负责授权流程和 token。
Casbin 是访问控制策略引擎，负责根据主体、资源、动作和策略判断是否允许访问。
OAuth 2.0：
客户端能否获得并使用 access token？
Casbin：
这个主体能否对这个资源执行这个动作？二者可以组合使用，但互相不能替代：
先认证并解析 token
↓
得到主体身份
↓
Casbin 或其他权限系统执行授权判断9. 学习时最容易混淆的点
- OAuth 2.0 不等于登录系统；
- client 不一定是浏览器，也可能是后端服务；
- authorization server 不一定和 resource server 分开部署；
- client_credentials 不涉及用户同意页和 redirect_uri；
- client_secret 只能放在可信后端，不能安全地放进公开前端；
- HTTPS、secret 保管、token 过期、撤销、scope 限制和日志脱敏都属于实际安全要求；
- 不要把数据库表名、角色命名和某个框架的实现方式误当成 OAuth 2.0 标准本身。
10. 一句话总结
OAuth 2.0 是“如何让客户端获得访问受保护资源的授权”的通用框架。
其中 Client Credentials 模式专门适合后端服务之间使用应用身份换取 token，再携带 Bearer token 调用 API。