使用 OAuth 2.0 进行授权时，如何防止未经批准的 3rd Party SPA 访问资源？答案

【问题标题】：How to prevent non-approved 3rd Party SPA access to resource when using OAuth 2.0 for authorisation?使用 OAuth 2.0 进行授权时，如何防止未经批准的 3rd Party SPA 访问资源？
【发布时间】：2019-05-10 14:54:37
【问题描述】：

我正在尝试仅允许通过批准的单页应用程序访问我们面向公众的 API。我们目前使用 OAuth 2.0 来控制对我们 API 的访问。高级场景是我们的用户将访问我们公开可用的 SPA，提供他们的用户名和密码，然后能够使用 SPA，而后者又能够使用我们的 API。

OAuth 2.0 与 SPA 的当前最佳实践是使用授权码授权和客户端 ID，但没有客户端密码，因为显然 SPA 无法保留任何密码。

我的问题是如何防止第三方 SPA 访问我们的 API。 IE。他们可以从我们的 SPA 中提取现有的 client_id 并以与我们的第一方 SPA 相同的方式请求授权码。假设他们可以说服用户登录，他们就可以访问我们的 API。在这种情况下，预注册的重定向 URL 是唯一的防御措施吗？如果是这样，这是否意味着如果我们切换到使用资源所有者凭据授予来获得更好的用户体验（我知道不推荐），就根本没有第三方应用程序的保护？

我已经阅读了 OAuth 的各种 RFC，尤其是这个页面非常有用，但并不能完全回答我的问题： https://auth0.com/blog/oauth2-implicit-grant-and-spa/

【问题讨论】：

公共客户端应该注册他们的重定向 URI。如果恶意应用程序试图获取访问令牌，授权服务器应该拒绝请求，因为重定向 URI 不在列表中

标签： oauth-2.0

【解决方案1】：

确实，在这种情况下，在公共客户端使用所谓的隐式授权类型时，预注册的重定向 URI 是唯一的防御机制。攻击者可能会欺骗用户启动流程，但不会在其控制的重定向 URL 上收到已颁发的令牌。这类似于诱使用户启动任何其他登录流程。

由于攻击者没有获得令牌（它仍然通过客户端控制的预期重定向 URI 传递），因此即使他可以说服用户登录，他也无法访问您的 API。

当攻击者控制 DNS 时，事情会变得更加危险，但这也适用于 OAuth 2.0 之外的许多事情。一般来说：无论使用何种协议，向浏览器内应用程序传递令牌都会遭受这种类型的漏洞。

切换到资源所有者密码凭据有很多缺点，包括攻击者可以提供与您的应用类似的应用来获取用户名/密码（这也会阻止您升级到多因素身份验证作为其他授权类型会允许你）。

总而言之：虽然不是超级强，但有针对它的保护。

FWIW：最新的 OAuth 2.0 最佳实践表明，令牌不应再直接传递到重定向 URI，而是使用中间短期使用的一次性使用授权码，以允许 SPA 在 XHR 调用中获取其令牌直接来自令牌端点。

【讨论】：

感谢您的解释。为了检查我的理解，即使使用预先注册的重定向 URL，攻击者能否更简单地忽略重定向但仍使用提供的授权代码或令牌（取决于使用的授权类型）？我想知道我是否在这里遗漏了一些非常明显的东西，但是如何阻止 malicoius SPA 使用浏览器获取 AP 或 XHR 使用用户名、密码和被盗的客户端 ID 调用授权 URL，然后简单地忽略重定向但提取来自 302 Location 标头的授权码？
他可以为为他生成的代码执行此操作，但不能为其他用户执行此操作
我更多地考虑了一个善意的第三方决定构建自己的第三方应用程序的场景。例如。假设 A 公司构建了一个供 B 公司员工使用的 SPA。B 公司的开发人员决定他可以构建更好的东西，而不是让他的新 SPA 在 A 公司注册，只需调用 A 公司授权 URL，忽略重定向（这可能使用合法的用户代理吗？），提取授权码，然后按照正常的 OAuith 2.0 流程获取访问令牌？然后，他说服他的员工使用他更新、更好的 SPA...
谁来“忽略重定向”以及攻击者将如何控制它？