Authentication JHipster-单页应用程序-OAuth2/OIDC和访问令牌位置

注意，我对OAuth2和OpenID Connect非常陌生，所以我可能有点困惑。好的，2021年建议使用OAuth2的身份验证流是授权代码流。我已经读过这本书了

我已经使用JHipster（v6.10.5，而不是v7）初始化了一个具有以下配置的项目：

• 您希望创建哪种类型的应用程序单片应用程序（建议用于简单项目）
• 您希望使用哪种类型的身份验证OAuth 2.0/OIDC身份验证（有状态，可与KeyClope和Okta一起使用）
• 您希望为客户端使用哪个框架反应（即SPA应用）

我想知道为什么JHipster的实现是有状态的？（即使用HTTP会话cookie JSESSIONID；访问令牌和刷新令牌存储在后端，而不是浏览器端）

为什么不让浏览器充当OAuth 2.0客户端来执行身份验证，并将访问令牌和刷新令牌存储在浏览器端

我找不到任何解释

---

此外，还提到了一个模式，该模式解释了与公共客户端/SPA的OIDC授权代码流。

要完成Matt Raible注释，请访问：

[……]

在浏览器中处理访问令牌的另一个问题是，截至本出版物发布之日，没有安全的存储机制，JavaScript代码可以在其中保存访问令牌，以便以后在API请求中使用。使用OAuth流会导致JavaScript代码获取访问令牌，需要将其存储在某个位置，然后检索它以发出API请求

相反，更安全的设计是在JavaScript应用程序和API之间使用仅HTTP的cookie，这样JavaScript代码就不能访问cookie值本身。此外，SameSite cookie属性可用于防止CSRF攻击，或者，也可以编写应用程序和API以使用反CSRF令牌

[……]

但是，我认为在后端使用HTTP会话和OAuth2令牌可能会使一些问题的管理/实现变得复杂，因为我们必须处理不同的超时：

• 浏览器和后端之间HTTP会话的空闲超时
• 存储在后端的刷新令牌的过期超时或最大生存期过期

---

我现在想知道，当一些边缘案例发生时，如何提供用户友好的体验。例如：当刷新令牌在后端端已过期，但最终用户仍然连接，因为浏览器和后端之间的HTTP会话仍然有效。

也看到我们以这种方式实现它，因为它是最安全的，OAuth流发生在后端（后端通道）而不是前端通道（在浏览器中）。如果我们改为前端通道，我们必须在每个客户机框架中实现OIDC，而且它的安全性会降低，因为访问令牌将存储在客户机上。此外，JWT作为会话令牌。