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

幸运的是，每一次迭代，安全性都在变得更好，但这通常是以开发者更多工作为代价的。即将到来的 OAuth 2.1 标准将使一些当前的最佳实践成为强制性的，并包括强制性的 PKCE（今天只有少数 API 需要这个）和刷新令牌的额外限制。

文章插图

至少 OAuth 已经实现了一个双因素认证模型。©XKCD

最大的变化可能是由过期的访问令牌和刷新令牌的引入引发的。理论上，这个过程看起来很简单：每当一个访问令牌过期时，用刷新令牌刷新它，并存储新的访问令牌和刷新令牌。实际上，当我们实现这个功能时，我们必须考虑：

竞争条件：我们如何确保在我们刷新当前访问令牌时没有其他请求运行？
一些 API 也会在你一定天数内不使用它们（或者用户已经撤销了访问权限）时让刷新令牌过期。预计一些刷新会失败。
一些 API 在每次刷新请求时都会给你一个新的刷新令牌……
……但有些则默默地假设你会保留旧的刷新令牌并继续使用它。
一些 API 会以绝对值告诉你访问令牌的过期时间。其他人只以相对的“从现在开始的秒数”来表示。还有一些，比如 Salesforce ，不轻易透露这种信息。

最后：一些我们还没有谈到的事情
不幸的是，我们只是触及了你的 OAuth 实现的表面问题。现在你的 OAuth 流程运行起来了，你得到了访问令牌，是时候考虑以下问题了：

如何安全地存储这些访问令牌和刷新令牌。它们就像你用户账户的密码一样。但是单向加密不是一个选项；你需要安全的、可逆的加密。
检查授予的 scope 是否与请求的 scope 匹配（有些 API 允许用户在授权流程中更改他们授予的 scope）。
避免刷新令牌时出现多个请求同时修改同一个令牌的情况（也称为竞争条件）。
检测用户在提供者端撤销的访问令牌。
通知用户访问令牌过期，并引导他们重新授权你的应用。
如何撤销你不再需要的访问令牌（或者用户根据 GDPR 要求你删除的访问令牌）。
你还需要应对可用 OAuth scope 的变化、提供者 bug、缺失的文档等等问题。

有更好的方法吗？
如果你读到这里，你可能会想， “一定有更好的方法！”
我们认为有，这就是为什么我们正在构建 Nango：一个开源、自包含的服务，它提供了预先构建好的 OAuth 流程、安全的令牌存储和自动令牌刷新适用于 90 多个 OAuth API 。
如果你试一试，我们很乐意听到你的反馈。如果你想和我们分享你最糟糕的 OAuth 恐怖故事，我们也很乐意在我们的 Slack 社区中听到。
OAuth 的实践过程中，除了本文提到的问题外，还有哪些问题？

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