OAuth 2.0 是一个授权框架，用来让客户端在资源拥有者同意后，通过访问令牌访问受保护资源，而不需要拿到用户密码。
核心问题
没有 OAuth 时，第三方应用要访问用户数据，常见坏做法是让用户把主站密码交给第三方。OAuth 把“授权访问资源”拆成受控的 token 流程：用户在授权服务器上同意，客户端拿到有范围、有期限、可撤销的访问令牌。
核心对象
| 对象 | 作用 |
|---|---|
| Resource Owner | 资源拥有者，通常是用户 |
| Client | 想访问资源的应用 |
| Authorization Server | 认证用户、征得同意并签发 token 的服务 |
| Resource Server | 持有 API 或资源的服务 |
| Access Token | 客户端访问资源服务器时携带的凭据 |
| Scope | 限定访问范围的字符串，例如 repo:read |
核心机制
最常见的授权码流程是：
- 客户端把用户重定向到授权服务器。
- 用户登录并同意授权范围。
- 授权服务器把一次性授权码
code发回客户端。 - 客户端在后端用
code换取 access token。 - 客户端调用资源服务器 API，并携带 access token。
- 资源服务器验证 token 的签名、有效期、受众和 scope。
授权码不是访问凭据，只是一次性中间票据。它把浏览器前端和后端换 token 分开，降低 token 暴露在 URL、日志或浏览器环境中的风险。
工程用途
- 第三方应用访问 GitHub、Google、飞书等平台 API。
- 内部微服务用短期 access token 调用资源服务。
- CLI 或桌面应用通过授权码加 PKCE 获取用户授权。
- OIDC 复用 OAuth 流程，在其上增加身份认证语义。
边界与常见坑
- OAuth 2.0 本身不是登录协议：用户身份语义由 OpenID Connect 补上。
- scope 不是细粒度业务权限的全部：复杂 RBAC、租户边界和审批状态通常仍在业务系统里。
- access token 不应进前端日志：泄露后在有效期内可被重放。
- redirect URI 不能宽松匹配：否则授权码可能被转发到攻击者站点。
- 客户端类型不同，安全假设不同：浏览器、移动端和 CLI 不能像后端服务一样保密 client secret。