这是我第一次实施OAuth，所以我只是想绕过整个流程。
我正在尝试为Stripe Connect实施OAuth。因此，在步骤4中，您将向客户端秘密发送一个POST请求到Stripe服务器，我认为这意味着您的后端将处理它。
想确保我正确地考虑这个问题。用户使用Stripe进行身份验证后，它们将被重定向到您提供的链接（使用Auth Code作为参数）。您是否想要重定向回到前端客户端，然后前端客户端将该Auth Code发送到您的服务器，然后服务器将其发送给Stripe？或者您是否会重定向到后端的某个路由，然后再使用Auth Code并将用户重定向到前端客户端（少一个网络请求）？
编辑：看看这个example。因此，似乎用户实际上会向您的服务器发出GET请求，该请求会将它们重定向到Stripe，然后在进行身份验证后再向服务器上的另一条路径发出另一个GET请求。
编辑2：经过一些挖掘后，这就是我认为我要做的事情：
如果我理解正确，重定向链接应指向您的后端服务器。然后，您的后端服务器上的此重定向路由会在步骤4中向Stripe的端点发出请求。
在许多情况下，访问令牌和刷新令牌存储在数据库中，以供将来对此用户请求。这些令牌是非常敏感的信息，可用于制作条带事务，因此最好不要在前端公开它们。
我也开始对OAuth的东西感到困惑。
回答提问者的编辑＃2：
在＃2上，我不确定在向Stripe发送初始请求之前是否需要命中服务器。这些“通过..注册”按钮直接链接到服务是很常见的。所以，可能有<a>按钮，有像href="https://connect.stripe.com/express/oauth/authorize?redirect_uri={URL}&client_id={ID}&state={STATE_VALUE}"。当用户访问页面时，可以生成STATE_VALUE。
然后，当用户单击该按钮时，用户将导航到Stripe的注册/登录页面。当用户完成填写表单时，Stripe将用户带到'redirect_uri'。在这里（＃5），我不太清楚你的意思是'用户被重定向到我前端的加载页'。我在想，这是你的应用程序的一个URL，所以这个请求必须打到你的服务器。除非请求是由ajax发出的，否则用户刚来的页面无法接收和处理响应。在Stripe的情况下，看起来它们的流程是为简单的html请求而设计的。 （某些服务可能通过ajax执行此操作，在这种情况下，前端代码中存在响应处理。）
因此，您的服务器从Stripe接收身份验证代码。服务器检查STATE_VALUE，使用auth代码向Stripe发出POST请求，从Stripe接收秘密/刷新密钥。然后，服务器可以使用适当的页面响应用户。
我想你可以让你的服务器在发出最后一个POST请求之前立即响应，并让前端代码通过ajax执行，并在发出请求时显示加载页面。但是，我不同意这是一个不错的选择;在我看来，它可以暴露敏感信息，而加载时间不足以成为一个糟糕的用户体验。
所以从浏览器的角度来看，
当用户单击指向Stripe登录的链接时
- >向Stripe的auth页面发出请求
- >从Stripe接收包含表单的页面
当用户提交条带表单时
- >向Stripe发出请求以提交表单
- >从Stripe接收302，重定向到你应用的重定向网址（包含auth代码）
- >向您的服务器发出请求
- >从服务器接收新页面
随意评论/纠正。
我个人将它们重定向到一个前端页面，该页面将授权代码发送到我的后端服务器，这样我就可以在完成用户委派的授权过程时呈现加载动画。这样，用户就知道发生了什么，并且不会挂在慢速身份/授权服务器上。无论哪种方式都很好，并且重定向到'后端'上的路由（没有前端视图的路由是我认为你的意思），最终将用户重定向到具有前端视图的路由（取决于授权是否结果）在成功或失败中）也没关系。