The token exchange functionality would be potentially useful for a project we’re working on; is there any planned timescale as to when it will be “supported” rather than in “preview”?
From my PoV, the functionality is pretty much stable in regards to the basis of token exchange (between apps and apps and brokers). The missing bits would be to reviewing the implementation based on the latest specification and, mainly, some KC-specific bits that exists.
Many thanks for your reply; not going to hold you to this 
but do you think that this is something that would become officially stable this year, early next year, or beyond…?
Btw, could you describe more your use case in regards to token exchange, what capabilities are you using and, if possible, what you are missing or you think we need to improve?
This is our use case and currently proposed solution - please let us know if this isn’t the right way to do this…!
We’ve got a series of legacy systems (web front end, mess of backends, including a mainframe) that currently deal with authentication and session state management. We’re trying to replatform to a microservices architecture with JWT-based authorisation, on the back-end initially (i.e. still behind the legacy web layer, but teasing functionality out into microservices, piecemeal)
For now, and for the short-to-medium term, all authentication is done by the legacy web layer; but we need to translate that into JWTs to allow us to call out securely to microservices.
Essentially, our legacy systems are the authentication (ID) providers, but they don’t provide any SAML/OIDC integration.
Our thought was that our two separate legacy systems, when they go off to call a microservice, generate and sign an ID token on behalf of the user that they’ve authenticated, containing the CustomerID and potentially some other customer metadata within the signed JWT.
The legacy systems then use External-to-Internal Token Exchange to get a KeyCloak generated JWT, with the customer metadata then mapped into that JWT. The legacy systems then use the KeyCloak generated JWT to access the services on behalf of the customer.
The service being called then validates that JWT, and if that service needs to call another service with a different scope, it uses Internal-to-Internal Token Exchange.
Upshot is, the services only need to trust KeyCloak; KeyCloak trusts itself and the Legacy ID Providers.
Eventually, we decouple the session-based user authentication from the legacy systems and do it properly using OIDC; the services then have no idea that it’s changed.
1 Like
Thanks for the details.
Like you said, the capabilities provided so far should be enough to address your requirements.
By brokering your legacy identity providers (IdP) I guess you have implemented a custom identity provider/broker in Keycloak ?
In general, looks like a perfect use case for token exchange and how, when combined with brokering, you can leverage legacy systems/infra as well as replace it over time with OIDC/OAuth2.
Sorry to hijack the topic, but I’m in very similar situation, as I reported on this other post Integrate with legacy system, with a slight difference as we are also providing a web UI.
Can you provide additional information on how this token exchange can be performed? I’m stuck after signing-in on behalf of the user…
Could I ask a dumb question regarding the token exchange funcionality in 8.0.1 Keycloak version? We have started the server with
Dkeycloak.profile.feature.token_exchange=enabled
But I do not see the Permissions tab as it is shown in the documentation. Could you please point me to the documentation how to enable the Clients permissions tab? What else is needed except Dkeycloak.profile.feature.token_exchange=enabled?
Thank you in advance for help.
Documentation is missing this part, but you also need to enable admin_fine_grained_authz.
Thank you very much for quick response.
Just adding to the queue of people interested in the feature. From my experiments, it seems to be working as advertised.
Looking at the docs, it was marked as “preview” ever since Keycloak 4 and maybe before. We are now at Keycloak 10, so I was wondering if it’s no longer being actively developed?
Maybe it’s just difficult to get right and secure at the same time (you don’t want to mess this up hence forever in beta).
Personally I would like this approved for prod. It is extremely important to be able to retrieve (exchange) token for the original external or other linked token. It would allow to open variety of capability directly from the client instead of dispatching those through a custom api-based mechanism.
I have a silly issue in 8.0.1 I can’t even get the basic ExtIDP retrieved.
Hello,
we also want to use the Token Exchange feature to get multiple, specialized access tokens for different backends.
I have seen that the OAuth 2.0 Token Exchange Specification was published in Jan 2020. And I couldn’t find big differences between the official spec and Keycloaks implementation.
Is there a documentation available that describes a bit more in detail why Token Exchange is still only preview and when it will become an official feature?
Best regards,
Hermann
Hi, for me this is important to authorization servers in distributed operations.
The IDP can be unique and federated. But once you have a token, if you want to call a service from any other realm, for example another product from another team in your company, ask for a token first by using token exchange. After all, the others don’t need to know about users etc, but they need an authorization server that they trust.
As I have indicated in another post, this seems to me to indicate that Keycloak is less of an authorization server than an identification server.