Enhance OIDC token propagation filters to select named OIDC clients

[sberyozkin]

Description

OIDC token propagation filters, before propagating the tokens, can exchange them with the OIDC server to set the correct target service audience, with this token exchange supported by a named OIDC client.
Right now, it is not possible to associate a specific named OIDC client with a specific REST Client annotated with the @AccessToken which enabled a token propagation filter for this REST Client, see #36440

Implementation ideas

Allow to use @AccessToken like this:

@AccessToken("named-oidc-client")
interface MyRestClient {
   @GET
   String getData();
}

Similarly to how it can be done for OidcClientFilter.

Additionally it should be possible to use @AccessToken to customize an exchange token requirement when a default client is used as it is not really needed for named clients

[quarkus-bot]

/cc @pedroigor (oidc)

[quarkus-bot]

@sberyozkin triage/backport* labels may not be added to an issue. Please add them to the corresponding pull request.

_{This message is automatically generated by a bot.}

[sberyozkin]

I got this enhancement request closed by mistake

[michalvavrik]

I'll have a look.

Additionally it should be possible to use @accesstoken to customize an exchange token requirement when a default client is used as it is not really needed for named clients

@sberyozkin can you give me a hint what you meant by this - how should it be possible to customize exchange token requirement? Or at least what should be possible to do, I just need little context, link or class reference, not much. Thanks

[sberyozkin]

Hi @michalvavrik OIDC token propagation filter, before propagating the token, can exchange it first, using the token exchange grant or jwt bearer grant, and then will propagate the new token. And it can vary one per client case, for one client the token can be propagated immediately, for another one - after an exchange, but OIDC token propagation config is not multi-tenant, like the OIDC client configuration is...

I'll need to refresh my memory, what exactly I meant it can only be of interest to the default client.
Please look at selecting the named clients only for now, and I'll update once I recall it :-)
Thanks

[michalvavrik]

I'll need to refresh my memory, what exactly I meant it can only be of interest to the default client.

Way I see it when you select @AccessToken("client-1") then you signal that token should be exchanged (otherwise why you bothered to specify the client anyway), however for default client you didn't specify any name, hence you should also have additional option to enable exchange per AccessToken annotation instance.

[lmartella1]

Hello @michalvavrik, @sberyozkin would it be possible to backport this feature to quarkus 3.8? I see that only one of the two commits is part of the 3.8 release

[michalvavrik]

Hello @michalvavrik, @sberyozkin would it be possible to backport this feature to quarkus 3.8? I see that only one of the two commits is part of the 3.8 release

I think new features are not eligible for backports, even to LTS. However I'm not the one to decide. Let's see what @sberyozkin things.