Support a token exchange protocol for OIDC 'service' applications

[sberyozkin]

Description
As Stian @stianst and also Pedro @pedroigor have mentioned a bearer token coming into a service OIDC application may need to be exchanged for it to be correctly propagated (to retain a link with the original token, not to misuse the audience, scopes, etc).

Implementation ideas
Provide a pluggable TokenExchange interface (or may be use SecurityIdentityAugmentor) which would exchange the token before it has been prepared for the injection by the Arc producers.

Possibly a medium/longer term. Also CC @sebastienblanc and @stuartwdouglas

[pedroigor]

Another idea would be to enhance RESTeasy Client (or any other client library used by Quarkus users) to perform the exchange behind scenes when invoking some downstream service.

[sberyozkin]

@pedroigor in this case we'd need to make the incoming token available to the OidcClient (#5657) via a context propagation. We can have both options supported, the exchanged token can be qualified at the injection point to distinguish it from the incoming token

[stianst]

Right now token exchange is tech preview in Keycloak and we're not sure when we'd make it fully supported. Adding support for token exchange to Quarkus is probably something we could do as part of making token exchange supported.

[sberyozkin]

Hi @stianst @pedroigor I'm thinking of closing the issue for now and revisiting it later when we get some concrete user interest; or we can do some initial exchange support and let users experiment, what do you think ?

[pedroigor]

I vote for close and wait.

[sberyozkin]

Ok, let me close for now and we can quickly reopen once needed :-)

[sberyozkin]

Hey @pedroigor as discussed during the oidc-client PR review, I'm re-opening this issue so that we can review how to make the token-propagation case done such that the token acquires a new audience etc after the token exchange with Keycloak

[sberyozkin]

We can already re-sign the JWT token locally but if we want to preserve the token flow/transformation in the KC logs/etc then the exchange protocol would be the best indeed...

[lordvlad]

Hi @stianst @pedroigor I'm thinking of closing the issue for now and revisiting it later when we get some concrete user interest; or we can do some initial exchange support and let users experiment, what do you think ?

Where can I vote? :) I'd be interested in this feature. Currently, I do it with raw http calls since not even the keycloak java api supports the exchange properly.

[MadinaS]

any news in this case?