什么是 OAuth？

Source: Hacker News

背景

最近在 X（前身为 Twitter）上有人提问，想要一个 “Matt Levine 风格” 的 OAuth 工作原理解释，尤其是它为何被设计成现在这样。

“我迫切需要一个 Matt Levine 风格的 OAuth 工作原理解释。是什么历史上的需求层层叠加让我们走到这一步的？” – geoffreylitt

提问者并不想要低层次的各类流程细节，而是想了解塑造设计的 动机用例。

登录用例（OpenID Connect）

观察 OAuth 最直观的方式是通过 OpenID Connect（OIDC），它在 OAuth 基础上提供认证。OIDC 可以看作是一个 “魔法链接” 登录：

1. 服务器向只有用户能够访问的位置（例如用户的邮箱或移动应用）发送一个密钥。
2. 用户通过把该密钥返回给服务器，证明自己能够访问该位置。

如果密钥校验通过，用户即被认证。所有围绕的规范——词汇、用户体验细节以及额外的安全检查——都是在这个核心思路之上叠加的层。

为什么需要新标准

2006 年底，团队在开发 Twitter 时，希望支持 OpenID 1.0，以免 Twitter 成为中心化的身份持有者。然而，现有的 OpenID 流程需要密码，这在桌面客户端或新兴的移动应用上行不通。

其他站点也有临时方案（Flickr、AWS、Delicious 等），但它们 不安全且定制化。真正的需求是 一种标准、可靠的方式，让第三方应用在不暴露用户密码的前提下代表用户操作。

正是这个缺口催生了 OAuth，作为一种委托授权协议。

OAuth 的核心思想

本质上，OAuth 是一个两步过程：

1. 同意与密钥分发 – 用户（资源所有者）给出同意，授权服务器向受信任的委托方（客户端应用）颁发一个 多次使用的密钥（访问令牌）。
2. 令牌使用 – 委托方把该密钥提交给资源服务器，以代表用户执行操作。

其余的——刷新令牌、作用域、PKCE、令牌自省等——都是为让基本模式更安全、更可互操作而添加的额外机制。

历史背景

• 2006‑2007：第三方客户端需要无密码登录。
• 2007：第一版 OAuth 草案撰写。
• 2009：OAuth 1.0 发布（基于签名）。
• 2012：OAuth 2.0 发布，简化流程（Bearer 令牌）并加入可扩展性。
• 2014‑至今：在 OAuth 2.0 之上构建 OpenID Connect，提供标准化的认证。

这一演进体现了 安全性、可用性和可扩展性 之间的平衡。标准组织加入了“噪声”（例如令牌撤销、动态客户端注册）来应对真实世界的威胁和开发者体验。

实际要点

在实现 OAuth 时，先回答以下问题：

1. 你想实现什么目标？（例如，让移动应用能够代表用户发布内容。）
2. 为何需要委托？（例如，你不希望应用知道用户的密码。）

当目标明确后，OAuth 流程（授权码、隐式、客户端凭证等）就只是一套满足这些约束的机械步骤。

结论

OAuth 的设计根植于一个简单的问题：用户如何在不共享凭证的前提下，安全地授予第三方应用有限访问权限？ 其余规范则是多年增量改进、安全加固和共识构建的结果。

理解这一核心动机即可去除协议的神秘感，使其不再难以捉摸。