基于Keycloak集中认证+原有Web应用授权的方案及用户同步咨询

1. Keycloak认证+原有Web应用授权的主流最优方案 #

核心逻辑是让Keycloak仅承担身份认证职责，原有Web应用保留完整的授权决策能力，主流实现方式分两种：

• 基于OpenID Connect (OIDC) 的身份断言模式
  将原有Web应用配置为OIDC依赖方（RP），用户登录时跳转至Keycloak完成认证，Keycloak返回包含用户唯一标识（如sub字段）的ID Token和Access Token。原有应用验证Token合法性后，通过用户唯一标识关联本地存储的授权数据（如角色、权限记录），执行自身的授权校验逻辑。
  优势：完全遵循标准协议，无需修改Keycloak核心逻辑，原有应用仅需对接OIDC Token验证逻辑，兼容性强。
• Keycloak身份代理+原有应用授权校验
  将Keycloak作为前置身份网关，所有请求先经过Keycloak完成认证，认证通过后Keycloak将用户核心信息（如用户ID、用户名）以HTTP Header形式转发给原有Web应用。原有应用直接读取Header中的用户标识，调用本地授权服务完成权限校验。
  适用场景：不想在原有应用中集成OIDC客户端，可减少应用改造量，但需配置Keycloak反向代理规则。

两种方案都需确保：原有应用仅依赖用户唯一身份标识关联授权数据，本地不再存储密码等认证信息，彻底剥离认证逻辑。

2. 新用户创建/同步的实现方式 #

根据用户创建发起方不同，主流方案分为两类：

• 从原有应用发起创建，同步至Keycloak
  在原有应用的用户创建流程中，新增调用Keycloak Admin API的步骤，通过/admin/realms/{realm}/users接口创建Keycloak用户，同时保留原有应用本地用户记录。需确保两边用户唯一标识（如用户ID）一致，方便后续授权关联。可封装工具类处理API调用的异常重试、幂等性校验（如根据用户名判断用户是否已存在）。
• 从Keycloak发起创建，同步至原有应用
  利用Keycloak原生能力实现同步：
  • 用户存储SPI：自定义实现User Storage Provider，将Keycloak的用户操作（创建、更新）同步至原有应用数据库，相当于让Keycloak将原有应用用户库作为存储源之一，适合具备Keycloak定制开发能力的场景。
  • 事件Webhook监听：配置Keycloak在用户创建、更新等事件触发时，向原有应用提供的接口发送HTTP请求。原有应用接收事件后，在本地创建对应用户记录并初始化基础授权数据。

3. 第三方服务器处理用户创建的替代方案 #

新增第三方服务器的思路本质是做用户数据的中转协调，但多数场景下无需额外引入服务，更简便的替代方案如下：

• Keycloak事件监听+原有应用直接消费
  直接利用Keycloak内置事件系统，配置用户创建事件的Webhook，原有应用直接接收事件并完成本地用户创建。若用户从原有应用发起创建，则直接调用Keycloak Admin API，无需第三方中转，完全依赖原生能力实现双向同步。
• 将原有应用作为Keycloak用户存储源
  通过Keycloak的User Storage SPI，将原有应用用户数据库配置为Keycloak的用户存储源，Keycloak直接从原有应用读取用户数据。用户创建仅需在原有应用完成，Keycloak自动同步，省去额外同步逻辑，适合用户主要在原有应用创建的场景。
• 原有应用内聚同步逻辑
  若用户创建存在多入口，可在原有应用中封装统一的用户创建服务，同时完成本地数据库写入和Keycloak Admin API调用，将同步逻辑内聚到原有应用服务层，无需新增第三方服务器。

仅当用户创建流程涉及多异构系统且逻辑极度复杂时，才需要考虑第三方中转服务，常规场景下利用Keycloak原生能力即可解决问题。

内容的提问来源于stack exchange，提问作者BoldSheep