请注意，我对OAuth2和OpenID Connect很陌生，所以我可能有点困惑。AFAIK，2021年建议使用OAuth2的身份验证流是授权代码流。我已经阅读了RFC 6749。
我已经使用JHipster(v6.10.5，而不是v7(初始化了一个项目，配置如下：
- 您希望创建哪种类型的应用程序单片应用程序(建议用于简单项目(
- 您希望使用哪种类型的身份验证OAuth 2.0/OIDC身份验证(有状态，可与Keycloft和Okta一起使用(
- 您希望为客户端使用哪个框架React(即SPA应用程序(
我想知道为什么JHipster的实现是有状态的(即使用HTTP会话cookieJSESSIONID；访问令牌和刷新令牌存储在后端和NOT浏览器(。
为什么他们不让浏览器充当OAuth 2.0客户端来执行身份验证，并将访问令牌和刷新令牌存储在浏览器端？
我在JHisper安全页面上找不到任何解释。
此外，本博客还提到了一个模式，该模式解释了带有公共客户端/SPA的OIDC授权代码流。
要完成Matt Raible注释，请参阅OAuth 2.0 for Browser Based Apps-draft-ietf-OAuth-Browser-Based-Apps-07和§6.1。可以和资源服务器共享数据的基于浏览器的应用程序：
[…]
在浏览器中处理访问令牌的另一个问题是，截至本出版物发布之日，没有安全存储机制，JavaScript代码可以在该机制中保留访问令牌，以便稍后在API请求中使用。使用OAuth流会导致JavaScript代码获得访问令牌，需要将其存储在某个位置，然后检索它以发出API请求。
相反，更安全的设计是在JavaScript应用程序和API之间使用HTTP-only cookie，这样JavaScript代码就无法访问cookie值本身。此外，SameSite cookie属性可用于防止CSRF攻击，或者，应用程序和API可被编写为使用反CSRF令牌。
[…]
然而，我认为在后端使用HTTP会话和OAuth2令牌可能会使一些问题的管理/实现复杂化，因为我们必须处理不同的超时：
- 浏览器和后端之间HTTP会话的空闲超时
- 存储在后端的刷新令牌的过期超时或最大生存期过期
我现在想知道当发生一些边缘情况时，如何提供用户友好的体验。例如：当刷新令牌在后端过期，但最终用户仍然连接，因为浏览器和后端之间的HTTP会话仍然有效。