使用Keycloak作为SSO提供商在API网关上通过授权代码流实现OIDC

问题描述 投票:0回答:1

我计划实现一个架构,其中:

API 网关与多个服务和 Vue.js 前端应用程序交互。 API 网关创建自己的会话,将用户请求链接到存储的令牌。 前端使用会话 cookie 与 API 网关进行通信。 身份验证通过 Keycloak 作为 SSO 提供者进行处理。 目标是让前端不知道实际的令牌,同时保持安全性和灵活性。

灵感来源:https://medium.com/@a.zagarella/microservices-architecture-a-real-business-world-scenario-c77c31a957fb

文章介绍了 Spring Cloud Gateway 的使用,但在我的例子中它将是 golang 上的 api gateway。

此场景中的身份验证流程示例 authentication flow in this scenario

请求访问资源服务器上受保护资源的请求示例: request for access to protected resources

实施此类设置的最佳实践有哪些?我应该注意哪些潜在的陷阱吗?

这种方法似乎与链接文章中描述的方法类似,但我想获得有关如何有效实施它的更多见解。

请提供以下指导:

如何在API网关上安全地存储和管理令牌 前端和 API 网关之间的会话管理最佳实践 如何处理令牌刷新和过期 我应该牢记的任何安全注意事项 我对如何平衡此架构中的安全性、易用性和可扩展性特别感兴趣。

感谢您的专业知识!

oauth-2.0 microservices keycloak openid-connect api-gateway
1个回答
0
投票

您链接的文章中的架构(网关配置为

oauth2ResourceServer
)是根据 Spring Security 团队(以及许多其他安全专家)的说法,不应该与单页面一起使用(例如您的 Vue 应用程序) )和移动应用程序:令牌不应离开您信任的服务器,并且来自用户代理的请求应使用同站点、仅 http 会话 cookie(以及 CSRF代币)。

因此,您在网关中存储令牌(配置为带有

oauth2Client
oauth2Login
)并在路由请求(使用
Bearer
过滤器)时用基于
TokenRelay
的授权替换基于 cookie 的授权的方法经常被提及为“OAuth2 BFF”(后端用于前端)。我在 Baeldung 上为此写了一篇文章,其中包含一个示例 Vue 应用程序。

© www.soinside.com 2019 - 2024. All rights reserved.