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

文章插图
Salesforce 的authorization_code OAuth流程。这个简单的10步过程的清晰视图有什么不好呢？
问题是，每个人对 OAuth 的理解都有不同的想法，所以你最终得到了很多不同的（子）实现。
问题 2：每个人的 OAuth 都有细微的不同
每个 API 都实现了不同的 OAuth 子集，这迫使你仔细阅读他们冗长的 OAuth 文档：
1、他们在授权调用中需要哪些参数？

对于 Jira ，你必须设置 audience 参数来指定你要访问的 Jira 实例的 URL 。Google 倾向于通过不同的 scope 来处理这个问题，但是非常关心 prompt 参数。与此同时， Microsoft 的某个人发现了 response_mode 参数，并要求你总是将它设置为 query。
Notion API 采取了一种激进的方法，摒弃了无处不在的 scope 参数。事实上，你甚至在他们的 API 文档中找不到“scope”这个词。Notion 称它们为capabilities ，并且你在注册应用时设置它们。我们花了 30 分钟的困惑时间才明白发生了什么。他们为什么要重新发明这个轮子？
offline_access 的情况更糟：现在大多数 API 都会在一段时间后让访问令牌过期。要获得刷新令牌，你需要请求“offline_access” ，这需要通过一个参数、一个 scope 或者你在注册 OAuth 应用时设置的东西来完成。询问你的 API 或 OAuth 医生以获取详细信息。

2、他们希望在令牌请求调用中看到什么？

一些 API ，比如 Fitbit ，坚持要在请求头中获取数据。大多数人真的希望它在正文中，编码为 x-www-url-form-encoded ，除了少数几个，比如 Notion ，它们更喜欢以 JSON 的形式获取。
有些人希望你用 Basic auth 来验证这个请求。许多人不在乎这个。但要小心，他们可能明天就改变主意了。

3、我应该把我的用户重定向到哪里去授权？

Shopify 和 Zendesk 有一种模式，每个用户都有一个子域名，比如 {subdomain}.myshopify.com 。是的，这也包括 OAuth 授权页面，所以你最好在你的模型和前端代码中构建动态 URL 。
Zoho Books 为不同地区的客户提供了不同的数据中心。希望他们记得他们的数据在哪里：要授权你的应用，你的美国客户应该访问 https://accounts.zoho.com ，欧洲客户可以访问 https://accounts.zoho.eu ，印度客户欢迎访问 https://accounts.zoho.in。列表还在继续。

4、但至少我可以选择我的回调 URL ，对吧？
我们可以继续说很久，但我们想你现在应该明白了。

如果你输入 http://localhost:3003/callback 作为 Slack API 的回调，他们会友好地提醒你“出于安全考虑，请使用 https” 。是的，也适用于 localhost 。幸运的是有解决方案可以在 localhost 上进行 OAuth 重定向。

文章插图

OAuth 太复杂了；让我们做一个更简单的 OAuth 版本，它有我们需要的一切！©XKCD

问题 3：许多 API 在 OAuth 中添加了非标准的扩展
尽管 OAuth 标准很全面，但许多 API 仍然发现它有一些功能缺失。我们遇到的一个常见问题是，除了access_token 之外，你还需要一些数据才能与 API 交互。这些额外的数据如果可以在 OAuth 流程中与access_token一起返回给你，会更方便。
但这确实意味着更多的非标准行为，你需要为每个 API 特别实现。
下面是我们看到的一些非标准扩展的列表：