Spring Authorization Server OAuth 2.0 – 实际部署问题

huangapple go评论68阅读模式
英文:

Spring Authorization Sever Oauth 2.0 - Real Deployment Issue

问题

目前我有一个前端服务器,一个 BFF(也称为网关的前端后端服务器),一个资源服务器和一个身份验证服务器。

BFF 配置为使用 Java Spring Boot 和 Spring OAuth 2 客户端依赖项。

每个 OAuth 流都通过 BFF 服务器完成。BFF 重定向到前端用户(浏览器)的身份验证服务器 URI 和端点。身份验证成功后,它存储访问和刷新令牌,然后从资源服务器获取资源。

在本地一切正常,我已经设置了一个自定义域名 "custom-domain",与 127.0.0.1 关联,以避免使用 localhost,因为由于重定向 URI 问题,不允许指定 "localhost" 作为重定向 URI。

此外,BFF 服务的上下文路径为 /client,以便与身份验证服务器不同,并且不在 cookie 上发生冲突(至少是我读到的,不知道是否正确)。

现在,我尝试在本地 Docker 中的 Kubernetes 集群中部署它们。所有 4 个服务将在同一集群中,并且它们都将是 ClusterIp。还将提供一个 Ingress 来路由集群中的流量。

我还有两个自定义域名:

  1. api.custom.com 链接到网关
  2. auth.custom.com 链接到身份验证服务器

然而,网关的发行者 URI(与集群内的身份验证服务器通信的地址)设置为 auth-server(Kubernetes 标签)。因此存在两种通信:

  1. FE - Auth 服务器,当 BFF 发送重定向 URI(auth.custom.com)时
  2. BFF - AUTH 服务器进行直接通信(auth-server)

不幸的是,出现了一个问题,首先,当 auth.custom.com/oauth2/authorize?response_type/* 到达身份验证服务器时,日志中将出现 Invoking ExceptionTranslationFilter,而在本地日志中将出现 Invoking OAuth2AuthorizationEndpointFilter(8/20)。

关于授权服务器以及与 Kubernetes 相关的问题,是否可以解释一下会话/域问题/主题?例如,授权服务器是否可以在同一集群内?它应该是 ClusterIP、NodePort 还是 LoadBalancer?什么会话/域问题可能会阻止授权工作流正常运行?

英文:

So, currently i have a front-end server, a bff( back end for front end server also named gateway ) , a resource server and the auth server.

The BFF is configured as java spring boot with spring oauth 2 client dependency.

Every oauth flow is done trought the BFF server. This BFF redirects to the front end user ( browser ) auth-server uris and endpoints . And after auth is successful then it stores the access and refresh token and then it fetches resources from the resource server.

On local everything is working, i have set up a custom domain "custom-domain" linked up to 127.0.0.1 in order to avoid localhost because of that redirect uri issue that doesn't allow you to specify "localhost" as a redirect uri.

Also, the BFF service has a context-path of /client in order to be different than the auth server and not have a clash on the cookies ( this is at least what i read idk if it is necesarily corect )

Now, i'm trying to deploy them in a kubernetes cluster on my local docker. All 4 services would be in the same cluster, and every one of them would be ClusterIp. Also a Ingress would be availbale to route traffic in the cluster.

I also have two custom domains:

  1. api.custom.com that links to the gateway
  2. auth.custom.com that links to the auth server

However, the issuer-uri from the gateway ( the address to comunicate with the auth server inside the cluster) is set to auth-server ( kubernetes label) . So there are two communications:

  1. FE - Auth server when bff sends the redirect uris ( auth.custom.com )
  2. BFF - AUTH server for direct communcation ( auth-server)

And unfortunately, there is a issue, first of all when the auth.custom.com/oauth2/authorize?response_type/* will reach the auth server, an Invoking ExceptionTranslationFilter will apper in the logs , unlike on the local logs where Invoking OAuth2AuthorizationEndpointFilter (8/20) is taking place.

Can session/domain issues/topics be explained somewhow regarding the authorization server as well as kubernetes related stuff?

For example, can an auth server be inside the same cluster? should it be cluster, node port , load balancer? What session/domain issues can prevent auth workflow from working properly?

答案1

得分: 1

以下是您要翻译的内容:

我的BFF教程已部署到一个K8s集群,并且其中的3个授权服务器(一个Keycloak实例)托管在同一个集群中。

授权服务器和BFF完全独立配置:不同的命名空间,不同的入口,甚至不同的子域(分别是oidc.c4-soft.combff.demo.c4-soft.com)。

此外,大多数路由由BFF本身处理(而不是入口),它是使用spring-cloud-gateway实现的,配置为OAuth2客户端,并使用TokenRelay过滤器进行配置(显然与您所做的类似)。

入口仅用于将oidc.c4-soft.com路由到Keycloak服务和bff.demo.c4-soft.com路由到BFF。如何处理基于路径的请求是通过spring-cloud-gateway配置来确定的,就像在K8s之外运行时一样。

资源服务器(REST API)和前端(Angular应用程序)都由BFF提供(并路由),这极大简化了CORS配置:请求具有相同的来源。

英文:

My BFF tutorial is deployed to a K8s cluster and one of the 3 authorization servers (a Keycloak instance) is hosted by the same cluster.

Authorisation server and BFF are configured completely separately: different namespaces, different ingresses and even different sub-domains (respectively oidc.c4-soft.com and bff.demo.c4-soft.com).

Also, most of the routing is handled by the BFF itself (not the ingress) which is implemented with spring-cloud-gateway configured as OAuth2 client and with TokenRelay filter (like you are doing, apparently).

The ingresses are used only to route oidc.c4-soft.com to the Keycloak service and bff.demo.c4-soft.com to the BFF one. What to do with a request based on its path is determined with spring-cloud-gateway configuration, just as when running outside of K8s.

Both resource servers (REST APIs) and front-end (Angular app) are served (and routed) by BFF, which greatly simplifies CORS configuration: requests have the same origin.

huangapple
  • 本文由 发表于 2023年5月13日 22:18:04
  • 转载请务必保留本文链接:https://go.coder-hub.com/76243193.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定