为什么需要 OAuth

一个常见误解

OAuth 经常被说成「第三方登录协议」。更准确地说：OAuth 是授权协议——用户允许一个应用访问自己在另一个服务中的部分资源。第三方登录通常是在 OAuth 之上再获取用户身份信息。

这个区别很重要。把 OAuth 当成「登录协议」，就容易在授权边界上犯错。

最糟糕的做法

假设用户想用 GitHub 登录你的系统。最糟糕的做法是：让用户把 GitHub 密码交给你。

❌ 用户 -> 你的系统「请告诉我 GitHub 密码」
   -> 你用他的密码登录 GitHub，读取所有信息

密码一旦交出，你就拥有了该用户在 GitHub 的全部权限，而且用户完全无法控制你看了什么。这也是为什么正规平台永远不会这么做。

OAuth 的价值

OAuth 解决的是：用户不暴露密码，只授权你的系统获得有限信息。

✅ 用户 -> 你的系统 -> 跳转 GitHub 授权页
   -> GitHub 展示「该应用将获取你的公开信息」
   -> 用户点击「授权」
   -> GitHub 颁发受限的 access token
   -> 你的系统用这个 token 获取被授权的信息

关键差异：

• 用户密码永远不会离开 GitHub。
• 授权范围用户可见可控（只授权公开资料，不授权仓库、支付等）。
• 授权可随时撤销。

为什么用户愿意

对用户来说，这解决了「记不住那么多密码」的问题，也避免了「为了一个小应用把密码交出去」的风险。对平台来说，这是标准的安全接入方式。

什么时候用 OAuth

• 第三方登录：让用户用 GitHub / 微信 / Google 身份登录你的系统。
• 资源授权：让应用访问用户在你的服务中的数据（如「用微信授权读取头像」）。
• 开放平台：让第三方应用代表用户调用你的 API。

如果你的场景是「同一组织内部多个系统共享身份」，那更贴近 SSO（上一章）；OAuth 更多面向跨信任域的第三方授权。两者可以组合，但不要混淆。

一句话

OAuth 的本质是把「你是谁」和「你授权我做什么」分开：密码属于平台，授权由用户说了算。下一节看最常用的授权码流程是怎么落地这一步的。

上一章节

OAuth 第三方登录

下一章节

OAuth 授权码流程