在我的案例中，我应该如何使用 OAuth 2.0 授权（React 前端，Spring Boot 后端）

Question

我对如何为我的网络应用程序使用 OAuth 2.0 授权感到有点困惑。

我了解 SPA 的隐式拨款现已停用，我应该使用授权拨款。

然而，我读过的文章和文档以及我看过的视频仍然留下了一些含糊之处。

如果我有一个 React JS 前端和一个 Spring Boot 后端，我会看到三种进行令牌交换的方法。因此，当用户单击登录时，我可以：

1)让我的 React 前端在没有客户端密钥的情况下执行授权授予，并按照 SPA 的 OAuth 2.0 文档的建议获取令牌

2）让我的React前端执行一半的授权，即获取授权码。然后将其传递到我的后端，以与客户端密钥交换授权代码以获取令牌，然后将此令牌传递到我的前端。

（这是这里推荐的方法：既然密码授予已被弃用，那么它的替代方案是什么？ OAUTH 2.0）。

老实说，我不明白这是如何工作的，因为前端和后端的客户端 ID 肯定会不同吗？

3）让我的 React 前端将授权流程委托给我的后端服务器，该服务器可以使用客户端密钥执行授权。

我是否误解了什么，或者所有这些方法都可能吗？这里推荐的方法是什么？

Answer 1

这些都是可行的，但是风险不同。最重要的区别可能是哪些组件在身份验证期间可以访问哪些内容。考虑一下这些组件中的每一个都可能受到损害，攻击者会获得什么。

让我们从上面的#3 开始。作为此应用程序的用户，我必须在 SPA 中输入我的凭据，然后 SPA 会将其传递到您的后端。凭证会同时泄露给 SPA 和后端，如果其中任何一个受到泄露，攻击者就可以直接访问用户名和密码对。如果没有必要的话，您可能不想冒这个风险。此外，如果身份提供者是公共身份提供者（不是特定于您的应用程序），则这将不起作用，即。我不想在您的应用程序中输入我的 Facebook 密码。

从这个角度来看，上面的#1 更好，因为您的后端永远无法访问实际的用户凭据（他们的密码）。根据实施情况，如果您将用户重定向到身份提供商以输入密码，SPA 也不需要访问权限，但这是用户体验的权衡。在这种情况下，SPA 和您的后端都有访问令牌，这很容易受到潜在的 XSS 攻击。如果其中任何一个受到损害，攻击者可能会获得访问令牌的访问权限并在其有效时使用它。

#2 进一步改进了这一点，SPA 永远无法访问访问令牌，只能访问授权代码。在这种情况下，SPA 可能会与您的后端进行常规会话（会话令牌可能位于 httponly cookie 中），这可以防止 XSS，并且后端可以使用交换的访问令牌查询它有权访问的任何资源。您可能会说 SPA 具有攻击者也可以交换访问令牌的身份验证代码，但一方面身份验证代码应该是一次性令牌，而且 SPA 不需要存储身份验证代码，它只需要将其传递给后端一次。

所有这些都存在并且可行的原因是因为有时出于安全之外的原因您无法执行其中一项或另一项。选择一种对应用程序中的组件暴露最少的东西，同时仍然满足功能、用户体验和其他要求的方案，并始终了解您隐式接受的风险。