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

Slack 有两种不同类型的 scope：作为 Slack 机器人持有的 scope 和允许你代表授权你应用的用户采取行动的 scope 。聪明，但是他们没有只是为每个 scope 添加不同的 scope ，而是实现了一个单独的 user_scopes 参数，你需要在授权调用中传递它。你最好注意这一点，并祝你好运找到对此支持的 OAuth 库。

为了简洁和简单起见，我们跳过了我们遇到的许多不太标准的 OAuth 流程。
问题 4：“invalid_request” —— 调试 OAuth 很难
调试分布式系统本就不易，如果服务返回的是广泛的、通用的错误消息，就更加困难了。
OAuth2 有标准化的错误消息，但它们在告诉你发生了什么方面，和标题中的例子一样有用（顺便说一下，这是 OAuth 标准推荐的错误消息之一）。
你可能会认为 OAuth 是一个标准，每个 API 都有文档，所以不需要调试。很多。我无法告诉你文档有多少次是错的。或者缺少细节。或者没有更新最新的变化。或者你第一次看它们时错过了什么。我们实现的大约 80% 的 OAuth 流程在第一次实现时都有一些问题，需要调试。

文章插图

Randall 似乎能看穿我调试 OAuth 流程的心情？©XKCD

有些流程也会因为看似随机的原因而中断：例如， LinkedIn OAuth 会在你传入 PKCE（Proof Key for Code Exchange）参数时中断。你得到的错误是什么？“client error - invalid OAuth request 。”这是……有说服力的吗？我们花了一个小时才明白传入（可选的，通常被忽略的）PKCE 参数是什么导致了流程中断。另一个常见的错误是发送与你预先注册的应用不匹配的 scope 。（预先注册 scope？是的，现在很多 API 都要求这样做。）这通常会导致一个关于 scope 有问题的通用错误消息。真是令人沮丧。
问题 5：在 API 之上构建应用需要繁琐的审批
事实是，如果你要利用第三方的 API 来为其他平台或服务构建应用，你可能处于弱势的位置。你的客户要求集成，是因为他们已经在使用其他系统了。现在你需要让他们满意。
客观地说，许多 API 都很灵活，提供了方便的自助注册流程，让开发者可以注册他们的应用并开始使用 OAuth 。但是一些最受欢迎的 API 需要在你的应用变成公开并且可以被他们的任何用户使用之前进行审核。再次公平地说，大多数审核过程都是合理的，可以在几天内完成。它们可能对于最终用户的安全和质量有净增益。

文章插图
但但是一些出了名的例子可能需要花费几个月才能完成，有些甚至要求你进入收入分成协议：

如果你想访问包含更敏感用户数据的 scope ，比如电子邮件内容， Google 需要一个“安全审核” 。我们听说这些审核可能需要几天或几周才能通过，并且需要你在自己这边做不少工作。
想要与 Rippling 集成？准备好回答他们的 30 多个问题和安全预生产筛选吧。我们听说获得访问权限需要几个月（如果你被批准的话）。
HubSpot、Notion、Atlassian、Shopify 和几乎所有有集成市场或应用商店的人都需要审核才能在那里上架。有些审核很温和，有些则要求你提供演示登录、视频演示、博客文章（是的！）等等。不过，在市场或商店上架通常是可选的。
Ramp、Brex、Twitter 和相当多的其他服务没有为开发者提供自助注册流程，而是要求你填写表单以获得手动访问权限。许多人很快就会处理请求，但我们仍然在等待一些人在几周后回复。
Xero 是一个特别极端的例子，它是一个收费的 API：如果你想超过 25 个连接账户的限制，你必须成为 Xero 合作伙伴并将你的应用列在他们的应用商店中。他们会从每个从那个商店生成的潜在客户中拿走（截至本文撰写时）15% 的收入分成。

问题 6：OAuth 存在安全性问题
随着 OAuth 的安全漏洞被发现，以及网络技术的进步， OAuth 标准也不断更新和完善。如果你想要实现当前的安全最佳实践， OAuth 工作组有一个详细的指南供你参考。如果你正在与一个仍然使用 OAuth 1.0a 的 API 合作，你就会意识到向后兼容性是一个持续的挑战。