基于Keycloak的多租户IdP代理POC技术疑问咨询

背景 #

我正在启动一项POC，目标是打造一个适配多租户架构的模块，为应用提供OAuth2 Access Token。目前我们已有负责管理用户、租户、模块及角色配置的微服务，且每个租户都配备独立的IdP。

我们计划评估Keycloak作为IdP代理的可行性，用Realm来做租户配置，不使用Keycloak内置的规则/组功能，通过自定义Claim Mapper从微服务拉取信息，以此定制生成的Access Token。

问题1：启用IdP代理时，Keycloak是否会存储用户名/凭证/令牌？若存在存储，能否禁用，或是该存储为必要功能？ #

• Keycloak做IdP代理时，默认会存储用户身份信息（比如用户名）和从上游IdP拿到的令牌（比如刷新令牌），但不会存储用户的原始凭证（像密码这类）。
• 存储上游令牌是必要的——Keycloak需要靠它帮用户刷新Access Token，或者实现跨IdP的会话管理。不过你可以调整配置，缩短存储令牌的有效期，或者在特定场景下禁用持久化，但这可能会导致部分功能失效（比如无法自动刷新令牌）。
• 用户身份信息的存储是为了关联Keycloak内部用户实体和上游IdP用户，要是完全不需要Keycloak的用户管理功能，可以试试用即时配置（Just-In-Time Provisioning），再设置用户实体的生命周期策略，比如会话结束后自动删除用户数据，但这得结合Keycloak的事件监听或自定义扩展来实现。

问题2：每个Realm都有独立的JWKs，是否可以统一使用一套？我们的应用已支持多租户，但管理多套JWKs的体验不佳。 #

• 默认每个Keycloak Realm的JWKs是独立的，因为Realm是隔离的安全域，但有两种方式实现统一：
  1. 自定义令牌签名配置：给所有Realm配置同一个密钥库（Keystore）里的密钥对来签名令牌。可以通过Keycloak全局配置、CLI或API修改，覆盖每个Realm的默认设置。但要注意，这么做会打破Realm间的密钥隔离，所有租户的令牌都用同一套密钥签名，得评估安全风险。
  2. 搭建统一验证层：不在Keycloak层面统一JWKs，而是在应用侧做一个统一的JWKS验证服务，聚合所有Realm的JWKs，应用只和这个统一服务交互。这种方式保留了Realm的密钥隔离，同时简化了应用配置。

问题3：是否可以禁用Keycloak的登录表单？我们不会将Keycloak作为IdP使用，客户端始终会选择自身的IdP进行登录。 #

• 完全可以禁用Keycloak的默认登录表单，操作步骤如下：
  1. 进入每个Realm的Authentication > Flows，修改Browser认证流程，删掉所有本地认证步骤（比如Username Password Form），只保留IdP跳转的步骤（比如Identity Provider Redirector）。
  2. 把Identity Provider Redirector设为强制跳转，或者让它根据客户端请求自动匹配对应的上游IdP。
  3. 另外要确保所有客户端的Access Type配置正确，还可以通过权限控制或自定义拦截器禁用Keycloak直接登录端点的访问权限。

问题4：此类场景下选用Keycloak是否合适？我们仅会用到其约10%的功能，是否应考虑使用Ory Hydra这类工具？ #

• 如果你只需要IdP代理、令牌自定义和多租户隔离这几个核心功能，Keycloak确实有点重——它内置了大量你用不上的用户管理、权限控制、规则引擎等功能，会增加部署、维护和学习成本。
• Ory Hydra更适合这种轻量场景：它专注于OAuth2/OpenID Connect的核心功能（授权服务器、IdP代理、令牌管理），没有多余的用户管理模块，更适合做"无头"认证中间件，配合你已有的用户/租户管理微服务使用。
• 但要注意：Hydra的自定义Claim功能需要通过OAuth2 Token Introspection或**自定义扩展（Hydra Plugins）**实现，而Keycloak的自定义Claim Mapper更成熟、配置更直观。如果团队已经有Keycloak使用经验，或者要快速搭建POC，Keycloak的开箱即用特性更有优势；如果追求轻量、可扩展，且愿意花时间定制Hydra，那Hydra是更好的选择。

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