Keycloak Broker对接Keycloak IDP后，curl获取用户Token失败咨询

• Keycloak Broker（此处的Keycloak2）默认不支持直接通过curl/API代理转发请求到IDP（Keycloak1）获取Token，它的核心设计是服务于浏览器端的OAuth2/OpenID Connect重定向认证流。

为什么你的curl请求会失败？ #

Broker的定位是「身份代理」，而非「API网关」：

• 用户通过浏览器访问依赖Keycloak2的应用时，会被重定向到Keycloak1完成登录，Keycloak1认证通过后向Keycloak2返回授权码，Keycloak2再用该授权码向自身Token端点申请并颁发自有Token给客户端，而非直接转发Keycloak1的Token。
• 直接用curl向Keycloak2的Token端点请求Keycloak1用户的Token，不符合Broker的工作逻辑，它不会处理这种跨IDP的直接代理请求。

如何实现类似需求？ #

如果需要获取Keycloak1的Token，或通过Keycloak2间接拿到相关凭证，有三种可行方向：

1. 直接请求Keycloak1的Token端点：跳过Broker，用客户端凭证或用户凭证直接向Keycloak1的/realms/{realm}/protocol/openid-connect/token发起请求，这是最直接的方式。
2. 通过Broker映射IDP凭证：在Keycloak2的身份提供者配置中，添加Token映射规则，将Keycloak1返回的Token（或特定Claims）嵌入到Keycloak2颁发的Token中。客户端拿到Keycloak2的Token后，可从中提取Keycloak1的相关信息（包括原始Token，只要在映射中配置）。
3. 自定义扩展实现代理：如果必须通过Broker代理请求，可以开发Keycloak SPI扩展，新增一个自定义端点，接收客户端请求后，内部向Keycloak1发起Token请求并返回结果。但这需要编写自定义代码，不属于默认功能。

关于Broker支持的认证流 #

Broker仅支持标准的浏览器重定向流，比如：

• Authorization Code Flow（推荐）
• Implicit Flow
  这些流需要用户参与浏览器跳转登录，curl无法完整模拟这类交互流程（除非手动处理Cookie、跳转状态等，但这不是Broker的设计场景）。

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