我有点困惑，我应该如何使用OAuth 2.0授权授予我的web应用程序。
我明白spa的隐式授予现在已经失效，我应该使用授权授予。
然而，我读过的文章和文档，以及我看过的视频，仍然留下了一些模糊。
如果我有一个React JS前端和一个Spring Boot后端，我看到三种方法可以进行令牌交换。所以当用户点击login时，我可以:
1)让我的React前端在没有客户端秘密的情况下执行授权授予，并按照OAuth 2.0文档对spa的建议获取令牌
2)让我的React前端执行一半的授权授予，即获得授权代码。然后将其传递给我的后端，与客户端秘密交换授权码以获得令牌，然后将此令牌传递给我的前端。
(这是这里推荐的方法:密码授予的替代方法'OAUTH 2.0)。
老实说，我不明白这是如何工作的，因为前端和后端的客户端id肯定是不同的?
3)让我的React前端将授权流委托给我的后端服务器，后者可以使用客户端秘密执行授权授予。
是我误解了什么，还是所有这些方法都是可能的?这里推荐的方法是什么?
这些都是可行的，但风险不同。可能最重要的区别是在身份验证期间哪个组件可以访问什么。考虑到这些组件中的每一个都可能被破坏，攻击者将获得什么。
让我们从上面的#3开始。作为此应用程序的用户，我必须在SPA中输入我的凭据，然后将其传递到后端。凭证将同时显示给SPA和后端，如果其中任何一个被泄露，攻击者将直接获得对用户名和密码对的访问权。如果没有必要，你可能不想冒这个险。此外，如果身份提供者是公共的(不是特定于您的应用程序)，这将不起作用，即。我不想在你的应用程序中输入我的Facebook密码。
从这个角度来看，上面的#1更好，因为您的后端永远无法访问实际的用户凭据(他们的密码)。根据实现的不同，如果您将用户重定向到身份提供者以输入密码，则SPA也不需要访问，但这是一个UX权衡。在这种情况下，SPA和后端都有访问令牌，这很容易受到潜在的XSS攻击。如果其中一个被攻破，攻击者可能会获得访问令牌的访问权，并在它有效时使用它。
#2进一步改进了这一点，因为SPA永远不能访问访问令牌，只能访问验证码。在这种情况下，SPA可能会与后端进行常规会话(会话令牌可能在httponly cookie中)，这对XSS是安全的，后端可以使用交换的访问令牌查询它可以访问的任何资源。你可以争辩说，SPA拥有验证码，攻击者也可以交换访问令牌，但一方面，验证码应该是一次性令牌，SPA也不需要存储验证码，它只需要将其传递到后端一次。
所有这些存在并可行的原因是因为有时出于安全之外的原因，您无法执行其中一个。选择将最少的东西暴露给应用程序中最少的组件，同时仍然满足功能、用户体验和其他需求，并始终了解您隐含接受的风险。