OAuth 2.0 是什么
一句话总结
OAuth 2.0 是一个授权框架——它解决”允许 A 访问 B 的数据，但 B 不用把自己的密码告诉 A”的问题。它本身不负责认证（证明你是谁），认证是它上面的 OIDC 干的。
🤔 为什么会有它 / 解决了什么问题
在 OAuth 出现之前，如果你想让一个第三方应用（比如邮件客户端）访问你的 Gmail，你只能把自己的 Gmail 密码给它。这有两个后果：
- 这个应用有了你全部权限（不只是读邮件，还能删邮件、改设置）
- 密码泄露了你也分不清是哪个应用泄的
OAuth 解决的正是这个”密码共享”问题：第三方应用拿到的不是你的密码，而是一张限定了范围和时效的授权令牌。
🔍 具体原理 / 运作逻辑
OAuth 2.0 定义了四个角色：
| 角色 | 是谁 | 例子 |
|---|---|---|
| Resource Owner | 数据的主人 | 你 |
| Client | 想访问数据的应用 | Grafana、邮件客户端 |
| Authorization Server | 签发授权令牌的服务 | Frappe、Google |
| Resource Server | 存数据的服务器（通常是 API） | Frappe API |
流程：你打开 Grafana → Grafana 说”我需要访问你的 Frappe 数据”→ 跳转 Frappe → 你点”同意授权”→ Frappe 给 Grafana 一个 Access Token → Grafana 拿 Token 调 Frappe API。
更硬核的技术细节（点击展开）
OAuth 2.0 定义了几种授权方式（Grant Types）：
- Authorization Code（最安全）：浏览器跳转 → 拿到临时码 → 后端用码换 Token
- Implicit（已废弃）：直接在前端拿 Token，不再推荐
- Client Credentials：服务对服务，没有用户参与
- Resource Owner Password：直接把用户名密码发给 Client（最不安全）
我们只用 Authorization Code + PKCE，这是 2026 年的安全标准。
🧭 什么情况下会用到 / 什么场景会遇到它
- 任何”用 Google/GitHub 登录”的按钮背后都是 OAuth 2.0
- 给 Grafana 配 OIDC 时，底层协议就是 OAuth 2.0
- 写一个调用第三方 API 的脚本，拿 Access Token 的过程就是 OAuth
⚖️ 副作用 / 代价 / 取舍
- 复杂度：OAuth 2.0 比直接传密码复杂得多，需要理解 grant type、redirect_uri、scope 等概念
- Bearer Token 风险：Access Token 本身不加密，谁拿到谁就能用（所以要 HTTPS + 短有效期）
🕰️ 来历
- OAuth 1.0：2007 年发布，用了复杂的签名机制
- OAuth 2.0：2012 年 RFC 6749，大幅简化，成为行业标准
- OAuth 2.1（草案）：合并最佳实践，强制 PKCE，废弃 Implicit Grant
🔗 关联 / 经常一起出现的概念
- OIDC：在 OAuth 2.0 上加了身份认证层，补上了 OAuth 缺失的”你是谁”
- Authorization Code Flow：OAuth 2.0 最安全的授权流程
- Access Token：OAuth 2.0 签发的”房卡”
- PKCE：OAuth 2.0 的安全加强插件
⚠️ 注意事项 / 常见误区
- OAuth 2.0 不是认证协议，它是授权协议。“用 Google 登录”这个功能是 OIDC 提供的，不是 OAuth 2.0
- Redirect URI 必须精确匹配（包括 http vs https、尾部斜杠），差一个字符就失败
📎 记忆锚点
OAuth 2.0 = 酒店前台。你告诉前台”让清洁工下午进我房间”，前台给清洁工一张限时房卡——清洁工不知道你的密码，房卡只开你的门，下午过后失效。
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-09 | 首次创建 | Frappe SSO/OIDC 集成准备 |