OAuth：它是什么、用例和快速了解它的指南

您是否曾经点击过“使用 Google 登录”，然后转到一个屏幕，显示“此应用程序想要访问您的个人资料，请允许吗？”。这就是 [OAuth0 正在工作。几乎没有一个使用它的人了解屏幕背后到底发生了什么。

本快速指南解释了 [OAuth1] 是什么、它何时发挥作用，以及最重要且最令人困惑的，它实际上解决了什么问题。这不是一个实施教程。这是您需要停止复制安全配置而不知道自己在做什么的概念性理解。

混乱是从名字开始的。很多人认为 [OAuth2] 是“登录”的意思。它在一定程度上起到了作用，但这种愿景掩盖了它的真实面目。正确理解这一点是将认真使用安全性的人和只是重复使用安全性的人区分开来的关键。

OAuth 到底是什么

OAuth 是一种授权协议，而不是[身份验证3。这一句话已经解决了一半的困惑。

授权回答“这个应用程序可以代表我访问什么？”。身份验证回答“你是谁？”。它们是不同的问题。 [OAuth4 是第一个创建的。

核心思想：[OAuth5 允许您授予应用程序对其他服务中的资源的有限访问权限，而无需交出您的密码。当照片编辑应用程序请求访问您的 Google 云端硬盘时，您无需向其提供您的 Google 密码。你授权它，谷歌会给应用程序一个临时的、受限的密钥，一个令牌，它只对你允许的有效。

这就是该协议的天才之处：在不共享凭据的情况下委派访问权限。密码永远不会离开您或原始服务的手中。

这个类比让一切都清楚了

想想代客泊车。当您把车交给代客泊车时，您不会交出房门钥匙或文件，您交出的钥匙只能在有限的时间内启动汽车并打开车门，以供特定用途。

[OAuth6 是数字世界的代客钥匙。它颁发的令牌具有有限的范围（它只执行已授权的操作），它是临时的（它会过期）并且可以撤销（您可以随时取消它，而无需更改所有内容的密码）。它是细粒度的、受控的和可逆的授权。

OAuth 出现的用例

理解具体案例可以修正这个概念。

最明显的是社交登录，“使用 Google、Facebook、Apple 登录”。这里，[OAuth7]（通常与身份层 OpenID Connect 结合使用）允许应用程序通过受信任的提供商确认其身份，而无需创建另一个密码。这是每个人都知道的情况，即使出于错误的原因。

另一种情况是应用程序之间的访问。一个可以读取你的日历的生产力工具，一个通过开放式金融连接到你的银行的金融应用程序，一个在社交网络上以你的名字发布的系统。每个人都使用 [OAuth8 来获得对其他地方托管的资源的有限权限。

还有API 和企业集成的情况。当组织的系统需要以受控且可审核的方式访问彼此的数据时，[OAuth9 提供了范围令牌机制。在公共部门和受监管的环境中，这种授予和撤销精细访问权限的能力对于合规性非常有价值。

流程快速指南

无需深入代码，基本流程是这样的：您（数据所有者）向应用程序请求服务。该应用程序会将您重定向到您的数据所在的服务。您在那里进行身份验证并批准请求的访问。该服务向应用程序返回受限访问令牌。只要令牌有效，应用程序就使用此令牌仅访问您允许的内容。您的密码永远不会通过该应用程序。正是这种设计使得 [OAuth10 在实施得当时更加安全。

最危险的概念错误

安全成熟度需要了解导致最多问题的错误：将 [OAuth11 当它是授权证明时将其视为身份证明。

[OAuth12 表示“此令牌可以访问此类资源”。它本身并没有说“这个人是某某”。任何将纯 OAuth 视为身份登录的人都会造成真正的漏洞。这就是 OpenID Connect 存在的原因，它是一个构建在 OAuth 之上的层，旨在正确处理身份。混淆两者是社交登录中经典漏洞的根源。

另一个常见的错误是要求的范围太宽泛。当应用程序仅需要部分访问权限时请求完全访问权限违反了最小权限原则。作为用户，请警惕要求过高的应用程序。作为建设者，只订购必要的东西，这是安全和对用户数据的尊重，这是[LGPD13 所强调的。

反思：权力与责任

[OAuth14解决了一个真实而优雅的问题，但也集中了风险。令牌是一把钥匙；如果信息泄露，就可以访问他授权的内容。这就是为什么实施与概念一样重要。

代币需要安全传输、有效期短、撤销和谨慎存储。该规范已经发展，当前的最佳实践推荐更安全的流程并阻止旧标准。在不了解这些细微差别的情况下实施 [OAuth15“从互联网复制”就像安装一把昂贵的锁并将钥匙留在地毯下一样。值得依赖成熟的库和成熟的提供商，而不是重新发明协议。

结束

OAuth 不是“登录方式”。这是一种在不移交所有事物的密钥的情况下委派访问权限的方法。理解这个区别，授权，而不是[认证16;有限范围的令牌，而不是共享密码，将机械使用转变为有意识的使用。

安全性不是要记住协议。这是关于了解每个部分保护什么和不保护什么。那些掌握了 [OAuth17] 概念的人可以做出更好的决策，减少他们不需要的东西，并在正确的时间产生不信任。

如果您正在实施社交登录或跨系统集成，那么在配置协议之前有必要了解协议。我的博客上还有关于安全性、[身份验证18]和数据保护的其他文本，如果您想讨论具体的访问架构，这就是有效的对话。

另请阅读

[应用程序中的身份验证 - 最佳实践与示例19
[授权和权限：防止未经授权的访问的最佳实践20
[应用程序身份验证：完整的安全性和用户体验指南21
[OAuth 什么 E22
[应用程序中的身份验证 - 使用清单的最佳实践23
[应用程序中的社交登录：实施和最佳实践24