使用Keycloak作为IdentityProvider时，是否需同步自建用户表？

答案是不需要强制这么做，完全取决于你的业务需求，下面分场景说明：

不需要自建用户表的场景 #

如果你的系统完全依赖Keycloak处理身份生命周期管理（用户创建、认证、角色/权限分配），那完全没必要自建用户表：

• 用户登录后，系统只需验证Keycloak颁发的JWT令牌有效性，解析令牌中的sub（用户唯一ID）、用户名、角色等信息，直接用于业务授权和逻辑处理。
• 所有用户信息的维护（比如修改密码、更新邮箱、禁用账号）都在Keycloak后台操作，系统不需要关心存储细节，只需要信任Keycloak的令牌即可。
• 典型场景：纯API服务、前端单页应用，这类系统只需要做身份验证和授权，没有额外的业务用户属性要存储。

需要自建用户表的场景 #

如果存在以下业务需求，就需要考虑创建本地用户表，并可能和Keycloak同步数据：

• 需要存储业务专属属性：Keycloak作为通用身份提供者，只适合存储基础身份信息（账号、邮箱、角色），如果你的系统需要记录用户的业务数据（比如订单历史、个性化配置、业务特定标签），这些数据应该存在本地业务库中，通过Keycloak返回的sub字段关联用户。
• 离线访问用户数据：如果系统需要在Keycloak临时不可用的情况下，仍能处理部分依赖用户信息的逻辑（比如查看历史订单），本地存储用户基础信息可以避免完全依赖Keycloak的可用性。
• 多身份提供者聚合：如果你的系统同时接入多个身份提供者（比如Keycloak+微信登录），需要统一管理所有用户数据，这时候本地用户表可以作为用户数据的聚合中心。

关于同步的注意事项 #

如果决定建本地用户表，同步逻辑并非必须，但要根据需求选择合适的方式：

• 登录时同步：用户首次登录系统时，将Keycloak返回的基础用户信息写入本地表；后续登录时，可根据需要更新本地表中的信息（比如角色变更）。这种方式简单，不需要额外的定时任务或Webhook。
• 主动实时同步：通过Keycloak的Webhook功能，在用户信息变更时触发系统更新本地表；或者定期调用Keycloak的API拉取用户数据进行同步。适合需要实时同步用户状态（比如账号禁用、角色调整）的场景。
• 注意：不要在本地存储Keycloak已管理的敏感信息（比如密码），密码等身份凭证完全由Keycloak维护，本地只需要存储sub（唯一关联ID）和业务专属数据即可。

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