Repository navigation
Replies: 3 comments 1 reply
|
We have a huge need for a user to login to a non Keycloak app, hit a button that creates a Keycloak token and then logs them in to a Keycloak client app. This is basically a token exchange, could be considered impersonation? |
|
I am not sure I understand the use-case. The more details can be good as from what you mentioned, it is hard to guess what is best approach... The target of standard token-exchange (and of this post) is about the use-case when Keycloak client The Note that both tokens are Keycloak tokens issued to the same realm and in both cases, user (aka. If you want anything different (like exchanging external tokens for Keycloak tokens or changing subject), then it is not standard token exchange, but something different (maybe federated token exchange, or subject impersonation, which are also supported in Keycloak, but as a preview features for now). |
|
@mposolda First of all, I really appreciate the introduction of the standard token exchange in Keycloak 26.2 - it's a big step forward in terms of clarity, structure, and ease of use compared to the legacy token exchange. The new flow feels much more streamlined and consistent. That said, I’ve run into a limitation that I was previously able to handle with the legacy implementation: With the legacy token exchange, this was relatively easy to configure. However, with the new standard token exchange, I don’t see an obvious way to apply this kind of control. I was thinking it might be possible using client policies, but haven’t found a way to do this based on the audience parameter. I noticed that Are there any plans to support filtering allowed target clients directly, either via configuration or policy? Thanks again for the great work on this new feature. Looking forward to seeing how it evolves! |
|
@mposolda We have several clients who require these capabilities, and it can be challenging to justify the use of preview features—especially since the official documentation advises against using them in production scenarios. Having a clear roadmap would help build confidence in adopting these functionalities and support the decision to rely on the platform when these specific use cases are required. Thanks again for the great work already done. 💪 |
Uh oh!
There was an error while loading. Please reload this page.
For Keycloak 26.2, we are planning to finally make the progress on token exchange support and promote it from preview. For now, the target is to support only internal-internal token exchange based on the token exchange specification .
We had some discussions within Keycloak team how to make it possible to support the standard token-exchange. We came with some thoughts and ideas. I've added them to this Google document .
Feedback is welcome in the comments on the google document or in this discussion.
All reactions