都 2023 年了，OAuth 为什么还是让人头疼？ _OAuth

【编者按】这篇文章介绍了 OAuth 的实践中的问题，如：OAuth 标准过于庞大和复杂、每个人的 OAuth 都有细微的不同、许多 API 在 OAuth 中添加了非标准的扩展、调试 OAuth 很难、在 API 之上构建应用需要繁琐的审批、OAuth 存在安全性问题等。作者构建的一个开源服务 Nango ，它旨在简化 OAuth 的流程和提高安全性，适用于多种 API ，来解决这些问题。
链接：https://www.nango.dev/blog/why-is-oauth-still-hard
作者 | Robin Guldener译者 | 明明如月
责编 | 夏萌
出品 | CSDN（ID：CSDNnews）

我们为 50 个最受欢迎的 API 实现了 OAuth 。结果：一言难尽。

文章插图
图源：nango.dev
OAuth 是一个标准协议，它支持 OAuth 2.0 的客户端库已经存在，几乎适用于你能想象到的所有编程语言。你可能因此会得出结论，有了客户端库，你应该能在大约 10 分钟或至少一小时内实现任何 API 的 OAuth 。然而，理想很丰满，现实很骨感。很难想象一个人能够在 10 分钟或一小时内实现任何 API 的 OAuth 。
实践中的 OAuth
我们针对 50 种最受欢迎的 API 使用了OAuth ，如 google (GmAIl、日历、表格等) ， HubSpot ， Shopify ， Salesforce ， Stripe ， Jira ， Slack ， Microsoft (Azure, Outlook, OneDrive) ， LinkedIn ， Facebook 和其他使用OAuth 的 APIs 。
我们的结论：现在 OAuth 的体验和 2008 年的 JAVA 的浏览器 API 差不多。虽然大家普遍认同事情应该如何做，但实际上每个 API 都有自己对标准的解读，实现上的差异和特殊性，以及非标准行为和扩展。结果是：每个细节都有可能出现问题和错误。
到底问题出现在哪里，让我们深入研究一下！
问题1：OAuth 标准过于庞大和复杂

"这个 API 也使用 OAuth 2.0 ，我们几周前已经做过了。我明天就能搞定。"——实习生的最后一句话

OAuth 是一个庞大的标准。它由官方网站上的 17 个 RFC（定义标准的文档）共同构成。它们涵盖了从 OAuth 框架和 Bearer 令牌到威胁模型和私钥 JWT 的所有内容。
你可能会问：“所有这些 RFC 都和一个简单的第三方访问令牌授权 API 有关吗？”你说得对。让我们只关注那些可能与典型的 API 第三方访问用例相关的东西：

OAuth 标准：OAuth 2.0 现在是默认的，但一些 API 仍然使用 OAuth 1.0a（而且 2.1 就要来了）。一旦你知道你的 API 使用的是哪个，继续下一步：
授权类型：你需要 authorization_code ， client_credentials ，还是 device_code ？它们分别是做什么的，你应该在什么时候使用它们？如果有疑问，就试试 authorization_code。
顺便说一下：刷新令牌也是一种授权类型，但它不是用来获取访问令牌，而是用来延长访问令牌的有效期。它们的工作方式是标准化的，但你如何首先请求它们却不是。稍后再说。
现在你已经准备好了你的请求，让我们看看官方 OAuth 参数；它们有 72 个，每个都有明确的含义和行为。你可以在这里查看它们。常见的例子有 prompt ， scope ， audience ， resource ， assertion ，和 login_hint。然而，在我们的经验中，大多数 API 提供者似乎和你现在一样对这个列表一无所知，所以不用太担心。

如果你觉得这还是太复杂了，需要学习很多东西，我们倾向于同意你的看法。大多数构建公共 API 的团队似乎也同意这一点。他们没有遵循完整的 OAuth 2.0 标准，而只是根据他们的 API 用例选择性地实现了一些 OAuth 功能。这导致了文档中很长的页面，概述了 OAuth 对于这个特定 API 是如何工作的。但我们很难责怪他们；他们只是想要提供一个好的开发者体验（developer experience ， DX），让他们的 API 更容易使用和理解，而不是遵循复杂的标准。他们可能认为 OAuth 2.0 标准太复杂或不适合他们的场景，所以他们只选择了一些他们认为有用的功能。虽然这可能是出于好心，但也可能导致混乱和不一致。