我试图仅允许已批准的单页应用程序访问我们面向公众的API。 当前，我们使用OAuth 2.0来控制对我们API的访问。高级别的场景是，我们的用户将访问我们的公共SPA，提供他们的用户名和密码，然后能够使用SPA，从而可以使用我们的API。
带有SPA的OAuth 2.0的当前最佳做法是使用具有客户端ID但没有客户端密码的授权代码授予，因为显然SPA无法保留任何秘密。
我的问题是我们如何防止第三方SPA访问我们的API。即他们可以从我们的SPA中提取现有的client_id，并以与第一方SPA相同的方式请求授权码。假设他们可以说服用户登录，然后可以访问我们的API。 在这种情况下，预注册的重定向URL是唯一的防御方法吗？如果是这样，这是否意味着如果我们切换到使用资源所有者凭据授予来获得更好的用户体验（我不建议这样做），那么根本不会受到第三方应用程序的保护吗？
我已经阅读了OAuth的各种RFC，尤其是此页面非常有用，但并不能完全回答我的问题： https://auth0.com/blog/oauth2-implicit-grant-and-spa/
答案 0 :(得分：2)
实际上，在使用所谓的“隐式”授予类型时，在公共客户端的情况下，预注册的重定向URI是唯一的防御机制。攻击者可能会诱骗用户启动流，但不会在其控制的重定向URL上接收已颁发的令牌。这类似于欺骗用户启动其他登录流程。
由于攻击者未获得令牌（令牌仍在由客户端控制的预期重定向URI上传递），因此即使他可以说服用户登录，他也无法访问您的API。
当攻击者控制DNS时，事情变得更加危险，但这在OAuth 2.0之外也有很多事情发生。一般来说：无论使用哪种协议，向浏览器内应用程序交付令牌都会遭受这种类型的漏洞。
切换到资源所有者密码凭据有很多缺点，其中包括攻击者可以提供与您相似的应用程序来获取用户名/密码的功能（这也使您无法升级为其他授权类型的多因素身份验证）会允许您这样做的。）
总之：尽管它不是超级强壮，但仍然有针对它的保护措施。
FWIW：最新的OAuth 2.0最佳做法建议，令牌不应再直接传递到重定向URI，而应使用中间的，短暂的一次性使用授权码来允许SPA在XHR调用中获取其令牌直接从令牌端点开始。