Oauth2.0身份验证流问题

jw5wzhpr  于 2023-10-15  发布在  其他
关注(0)|答案(1)|浏览(126)

我正在讨论一个关于Oauth2身份验证流的设计问题。一点背景:我们正在使用React开发一个客户端,并使用Java(Sping Boot )开发一个后端。将只有一个基于oauth2的登录与oauth2服务器,如keycloak托管在我们的AWS。
现在来说说问题:
由于我们使用的是REST,因此是一种无状态的方法,客户端似乎可以向keycloak发出任何Oauth2请求。这是一个安全问题,至少在我的脑海里。当客户端从keycloak中获取代码时,以及稍后keycloak的令牌(可以在我们整个公司中用作SSO),令牌将非常容易获取。我希望在后端看到Oauth2请求,因为后端将提供另一个JWT令牌,用于客户端和服务器之间的基本通信。
所以问题是,有没有更安全的方法来处理oauth2?后端不能触发前端中的任何东西(无状态和无状态)。

5rgfhyps

5rgfhyps1#

答案是“是的,有更安全的方法来处理oauth2”<:oD
更有建设性的是,最近一个非常流行的模式被称为BackendFFrontend,它正是你所寻找的。
它的工作原理如下:

  • 在服务器上设置中间件(BFF)
  • 将BFF配置为OAuth2客户端
  • BFF为前端保留会话:浏览器和BFF之间的请求使用secured(仅通过https交换),http-only(无法通过JavaScript代码读取)和理想的same-site会话cookie进行授权。它还应该受到CSRF攻击的保护(CSRF令牌可用于JavaScript代码,其值作为POST/PUT/DELETE请求的X-XSRF-TOKEN头返回)。
  • BFF处理登录、注销和令牌存储(通常在会话中)
  • BFF在将请求从前端转发到资源服务器之前,用Bearer访问令牌即时替换会话cookie。

这解决了两个安全问题:

  • 在您信任的服务器上运行的OAuth2客户端可以使用一个秘密并且是“机密的”:无论是移动的应用程序还是浏览器中基于JavaScript的应用程序都不能保密,必须配置为“公共”客户端,这意味着任何欺骗用户获取授权代码的人都可以轻松地将其转换为令牌(访问,ID和刷新)
  • 令牌(由BFF)保存在服务器上,永远不会暴露给JavaScript代码,甚至浏览器(作为对比,用于授权请求的会话cookie将暴露给浏览器,但对Javascript隐藏)。

当你使用React和Spring时,我看到了两个自然的选择:

  • 使用Next.js OAuth,其中OAuth2客户端是应用程序的节点部分(在服务器上)
  • spring-cloud-gatewayspring-boot-starter-oauth2-clientTokenRelay=过滤器配合使用

我个人倾向于第二种选择,我认为它更具可扩展性和多价性(会话可以使用spring-session在示例之间共享,它可以与React应用程序一起使用,而无需在服务器上使用节点部分,也可以与Angular或Vue应用程序一起使用等)。
我写了一个configuring a spring-cloud-gateway as a BFF的教程。它是用Angular编写的,但由于前端所需的只是设置window.location.href来触发登录,因此您应该能够将其移植到React。不需要JavaScript库来驱动authorization_code流,存储或更新令牌(这是由BFF完成的),也不需要对请求进行授权,因为会话cookie会自动附加到浏览器的请求中。
你也可以用Next.js前端引用这个other project,但它只是暂时在线,README是法语的。

相关问题