Security OAuth2私有应用程序的流程和最佳实践

请耐心听我解释我的问题以及我找到的解决方案/指南

说明：在我的公司，我们有一个产品，有多个模块。每个模块都是其独立的后端和前端。我们将JavaEE/JakartaEE和JAX-RS作为后端堆栈，并将其作为前端进行响应。到目前为止，我们使用的是通过会话使用JavaEE安全性的基本身份验证，但由于产品正在发展，我们需要移动客户端并允许第三方访问数据，因此我们决定将OAuth2/OpenID Connect集成到我们的应用程序中

由于有多个实现提供OAuth2功能，我们目前正在研究一些可用的选项。（例如）。我们将选择的决定取决于我们想要做多少工作来改变应用程序的现有结构，以及我们如何处理数据库中的用户。但是，无论我们选择哪种实现方式，我们都面临着类似的问题

问题

react应用程序如何处理登录过程和令牌存储

每个文档都说：如果用户未登录，则会重定向到登录页面。其中，在登录并获得同意后，他将被重定向回应用程序（显然是在完成oauth2工作流之后），并带有资源服务器的访问/ID令牌和/或刷新访问/ID令牌的刷新令牌

现在我不清楚的是：

• 由于这是我们自己的React应用程序，我们不希望显示同意屏幕，就像在Microsoft/Google等应用程序中，您看不到任何同意屏幕一样。我想这可以通过在请求本身中设置一个值来实现，或者根据客户端id跳过同意屏幕，但我只是想确定一下

• 下一步是在哪里存储访问和刷新令牌？访问令牌应作为承载令牌随每个请求一起发送。因此它可以存储在本地存储中，因为它们的寿命很短，但是刷新令牌应该安全地存储。就像在安全的http cookie中一样？。如果是这种情况，那么服务器必须设置它。如果这是正确的，那么流将是什么样子

  我们的React应用程序（未登录）

  -->

  登录页面（另一个React页面）

  -->

  用户输入凭据

  -->

  Java后端

  -->

  对用户进行身份验证

  -->

  启动OAuth2进程

  -->

  获取访问和刷新令牌

  -->

  将其设置为安全cookie

  -->

  将经过身份验证的响应与cookie一起返回前端

  -->

  登录页面重定向到上一页

  -->

  用户继续使用应用程序

  这感觉不正确。PKCE在这种情况下会有什么帮助

假设我上面写的是正确的，当用户从我们自己的应用程序或第三方应用程序登录时，我需要不同的登录流。但是，这可以通过检查客户端ID或禁用第三方客户端的密码流来确定

这同样适用于刷新令牌流。因为对于我自己的应用程序，我必须设置cookies，对于第三方，这必须直接从OAuth服务器进行

我阅读/研究过的资源：

编辑：添加我已阅读的更多链接

当然，还有来自凯斗篷和奥瑞·海德拉的各种著作和例子

我目前正在尝试Key斗篷和ORY Hydra，找出更适合我们需要的

提前谢谢大家

您不必显示同意屏幕。下面是一个使用授权码授权的React应用程序验证的示例：（完全公开，这在我雇主的网站上，但将与任何符合OAuth2的身份服务器一起使用）

简单的回答是，最好避免隐式授权，将访问和刷新令牌存储在某些中间件中，而不是浏览器中。链接中的示例使用100行express服务器，并将这些令牌存储在会话中

我写了一些关于PKCE的文章。摘录：

代码交换验证密钥（PKCE）RFC于2015年发布，并扩展了授权代码授权，以防止在非TLS连接上发生部分授权流时受到攻击。例如，在本机应用程序的组件之间。如果TLS存在漏洞，或者路由器固件已受损，并且正在欺骗DNS或从TLS降级到HTTP，也可能发生此攻击。PKCE需要向OAuth服务器发送额外的一次性代码。这用于验证请求是否未被拦截或修改

下面是您拥有的各种OAuth选项的分类（同样，这是在我的雇主的网站上，但将与任何符合OAuth2的identity server一起使用）：您可以为不同的客户端允许不同的流。例如，您可以为第三方使用授权代码授权，为您自己的应用程序使用资源所有者密码凭据授权（本质上是用户名和密码）

我不确定我是否回答了你所有的问题，但我希望其中一些问题会有所帮助。

应该咨询一下。尽管它仍然是一个“互联网草案”，但它已经成熟，并已由多个供应商实施

通常，无论使用承载令牌还是JWT，建议使用带有PKCE流的OAuth 2.0授权码

---

你也应该考虑阅读（如果没有密码）

如果我正确地理解了，这个例子中使用的中间件实际上就是我们的后端。它的工作原理与我在问题中描述的相同。前端将用户发送到登录页面，接收代码，将其发送到后端，后端将此代码发送到oauth服务器，并接收令牌，在会话中设置它们，然后