时间戳

首页 > 解决方案 > JHipster - 单页应用程序 - OAuth2 / OIDC 和访问令牌位置

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

问题描述

请注意，我对 OAuth2 和 OpenID Connect 还是很陌生，所以我可能有点困惑。AFAIK，2021 年推荐使用 OAuth2 的身份验证流程是Authorization Code Flow。我已经阅读了RFC 6749。

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

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

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

我在JHispter 安全页面上找不到任何解释。

此外，此博客还提到了一个架构，该架构解释了带有公共客户端/SPA 的 OIDC 授权代码流。

标签： authenticationoauth-2.0single-page-applicationjhipsteropenid-connect

解决方案

要完成 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 cookie ，以便 JavaScript 代码无法访问 cookie 值本身。此外，SameSite cookie 属性可用于防止 CSRF 攻击，或者，可以编写应用程序和 API 以使用反 CSRF 令牌。

[...]

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

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

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

推荐阅读