OIDC Token Propagation with Token Exchange for multiple clients

[lmartella1]

Hello,
I'm currently building a Quarkus application which exposes secured endpoints via OpenID Connect. The application receives access tokens as bearer when accessing one of those protected endpoints and then needs to perform different downstream REST Client calls to other secured microservices. I'm currently using the quarkus-oidc-token-propagation-reactive extension to perform a token exchange and transform the incoming JWT token into a new one meant for the specific audience of the target microservice.

The following configuration allows me to properly do the token exchange but it applies in the same way to all the REST Clients annotated with @ AccessToken:

quarkus.oidc-token-propagation-reactive.exchange-token=true

quarkus.oidc-client.auth-server-url=${keycloak.url}/realms/quarkus/
quarkus.oidc-client.client-id=quarkus-service-app-frontend
quarkus.oidc-client.credentials.secret=secret
quarkus.oidc-client.grant.type=exchange
quarkus.oidc-client.grant-options.exchange.audience=quarkus-service-app-backend
quarkus.oidc-client.grant-options.exchange.subject_token_type=urn:ietf:params:oauth:token-type:access_token
quarkus.oidc-client.grant-options.exchange.requested_token_type=urn:ietf:params:oauth:token-type:access_token

My question is: what to do in case each REST Client need to have a specific NamedOidcClient to be used when performing the client call?

For instance, imagine that the microservice needs to perform two REST Client calls to two different microservices having different clientIDs: serviceA and serviceB.

In this case I would need the token exchange towards serviceA to use a NamedOidcClient called serviceA and having:

quarkus.oidc-client.serviceA.grant-options.exchange.audience=quarkus-service-app-A

while the calls towards serviceB uses a NamedOidcClient called serviceB and having:

quarkus.oidc-client.serviceB.grant-options.exchange.audience=quarkus-service-app-B

Looking at the quarkus-oidc-token-propagation-reactive documentation I don't see this approach as currently feasible. Am I wrong?
Thanks in advance.

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

Hi @lmartella1

I'm currently using the quarkus-oidc-token-propagation-reactive extension to perform a token exchange and transform the incoming JWT token into a new one meant for the specific audience of the target microservice.

Sound approach indeed

Looking at the quarkus-oidc-token-propagation-reactive documentation I don't see this approach as currently feasible. Am I wrong?

You are right. It is now possible to inject named clients to OIDC Client filters (done by @michalvavrik ) but not yet to Token Propagation filters.

I'll do a minor update to let users create custom token propagation filters customizing OIDC client names, which will do in the short term. And will open an enhancement request to support injecting named clients to the token propagation filters

[sberyozkin]

@lmartella1 See #36459, hopefully will make it to 3.5.0.
This is a short term solution, you'd have to create a custom token propagation filter and set a required OIDC client name and while it is not perfect, it should do for now.
Going forward, we'll try to resolve #36458 but it will take awhile

Thanks

[lmartella1]

Hello @sberyozkin,
Thank you for your promptness. Any chance to have it backported on 3.2?

Another point I noticed is that today is not possible to define in the same application a REST Client which is configured to do pure token propagation (the same bearer token in inbound is sent outbound) and another REST Client configured to do token exchange since the available configuration quarkus.oidc-token-propagation-reactive.exchange-token globally applies to all the classes annotated with @ AccessToken. I believe that making this configuration option to be per-rest-client-interface defined could be another point of improvement.

Thank you again,

[sberyozkin]

@lmartella1, hi,

Thank you for your promptness. Any chance to have it backported on 3.2?

Np, added backport labels up to including 3.2

Another point I noticed is that today is not possible to define in the same application a REST Client which is configured to do pure token propagation (the same bearer token in inbound is sent outbound) and another REST Client configured to do token exchange since the available configuration quarkus.oidc-token-propagation-reactive.exchange-token globally applies to all the classes annotated with @ AccessToken. I believe that making this configuration option to be per-rest-client-interface defined could be another point of improvement.

Indeed, it is a restriction but my understanding is that as far as the token propagation is concerned, the token exchange is a design/architectural decision - one either decides it is essential or not for a given system, i.e I'm not sure a situation where it is done for some token propagation cases but not for others in scope of a single frontend endpoint is very practical ? What do you think ?

If you will have such a prod-level requirement, then I'll have no problems with updating the filter code to let users customize the exchange token flag at a custom token propagation filter level, exactly as was done in #36459.

[lmartella1]

We indeed plan to have this setup implemented in a production environment: we imagine some microservice sharing the same clientID and therefore requiring simple token propagation when interacting each other while other microservices will have a different clientID resulting in the need of a token exchange.

Definitively have this kind of hybrid setup on which a given quarkus application is able to do pure token propagation or token exchange based on the target REST Client is something we need to find a proper balance between security scoping and latency+cpu cost drawbacks.

[sberyozkin]

@lmartella1 Sure, please see #36501, I also updated the #36458 requirements (though as I said it will likely take a while), thanks