基于RBAC与Keycloak实现服务间授权的最优方案咨询

系统架构与问题场景 #

我们的Web系统包含：

• 前端客户端
• 实现OAuth2.0的Keycloak
• 3个后端服务
  • OrangeService：存储Orange实体信息
  • AppleService：存储Apple实体信息
  • JuiceService：异步制作果汁的服务，make_juice操作耗时约10分钟
• access_token有效期为1分钟

核心流程与问题：

1. 用户John Doe通过Keycloak认证后进入前端，访问苹果/橙子页面时，数据服务（AppleService/OrangeService）会通过JWT向Keycloak查询UMA权限，控制用户可访问的实体。
2. 用户发起长耗时的制作果汁请求后，JuiceService校验权限并将任务放入队列，Worker执行任务时需要调用数据服务，但原access_token有效期过短无法复用，且Worker请求需关联John Doe的上下文以校验实体权限。

推荐解决方案 #

1. 委托令牌（Delegated Token）+ 客户端凭证流 #

• JuiceService接收前端请求并校验用户权限后，以自身客户端凭证向Keycloak申请带有John Doe标识的委托令牌，设置有效期匹配任务最长执行时间（如15分钟）。
• Worker执行任务时，使用该委托令牌调用数据服务。数据服务通过Keycloak的UMA接口，结合令牌中的用户标识，实时校验John Doe对目标实体的访问权限。
• 优势：既验证了Worker请求的合法来源，又能获取用户实时权限，避免权限过期问题。

2. Refresh Token + 服务端令牌刷新机制 #

• 前端发起长任务请求时，除access_token外，一并传递对应的refresh_token给JuiceService。
• Worker调用数据服务前，使用保存的refresh_token向Keycloak申请新的access_token，确保令牌始终有效。
• 注意：在Keycloak中配置refresh_token有效期覆盖任务时长，同时设置合理的刷新次数限制，降低安全风险。

3. 用户到客户端的权限委托（User-to-Client Delegation） #

• 在Keycloak中配置JuiceService拥有代表用户访问数据服务的权限，开启on-behalf-of模式。
• JuiceService使用自身客户端凭证向Keycloak申请带有John Doe上下文的令牌，Worker携带该令牌调用数据服务。
• 数据服务验证令牌时，可确认请求来自合法的JuiceService，同时通过令牌中的用户信息，实时查询Keycloak校验用户的实体访问权限。

不理想的方案说明 #

• 延长JWT有效期：令牌泄露后风险大幅提升，安全性极差，不可采用。
• 仅在代理/网关实现授权逻辑：服务自身失去权限校验能力，攻击者绕过代理后可直接访问数据，安全隐患极大。
• 为后端服务创建Keycloak用户：导致用户体系混乱，无法关联John Doe的上下文，无法校验用户级别的实体权限。

内容的提问来源于stack exchange，提问作者Игорь Пронин