Oidc-client: Custom dynamic headers

[rkraneis]

We want to interface with an API using OpenID connect and on top of that the upcoming HTTP Message Signing standard. This requires us to modify the headers of the token requests based on the body contents before those token requests are sent out via Vert.x. As of now, we did not find a solution short of reimplementing OidcClient (to at least keep the token cashing infrastructure). Is there a better way (maybe vert.x equivalent of MessageWriterInterceptor)?

[sberyozkin]

@rkraneis Can you please clarify, do you refer to quarkus-oidc-client ?
In this case you can use the dynamic client creation feature, see: https://quarkus.io/guides/security-openid-connect-client#use-oidcclients.

So you can inject OidcClients, create OidcClientConfig dynamically (it allows to set the custom header) and create the client.
Does it help ?

[sberyozkin]

@rkraneis

That may undermine the intended security a bit too much, as I would have to fix the supposedly random nonce to a static value and put the required expires parameter far into the future. But with the known OIDC Json payload I may still set these values correctly if I can create a dynamic configuration source for OidcClientConfig.headers ...

and

Alas, this doesn't see to be possible. Most of the OidcClientConfig doesn't seem to be interceptable

Then as I said earlier, use the dynamic OidcClient creation

@GET
    public String getResponse() {
        OidcClientConfig cfg = new OidcClientConfig();
        cfg.setId("myclient");
        cfg.setAuthServerUrl("http://localhost:8081/auth/realms/quarkus/");
        cfg.setClientId("quarkus");
        cfg.getCredentials().setSecret("secret");
        
        // calculate the headers now, with a new nonce every time

        Uni<OidcClient> client = clients.newClient(config);
        // use this client to get the token
    }

If you also disable the discovery and only point to the token endpoint directly with the config then the cost of creating a new client per every call will be close to 0...

[rkraneis]

@sberyozkin, thanks for the additional hint. Aren't acquired tokens bound to the current client instance? That's at least the impression I get from TokensHelper. If I create a fresh client for every intercepted request (I use ReastEassy to access the API), I will have a call to the token endpoint before every call also, right?

[rkraneis]

OK, after reading the code more carefully, I see that I just need to keep an instance of TokenHelper around. Thank you, that should solve the issue.

[sberyozkin]

@rkraneis Np, thanks, hope it will work well. If you'd like please create an enhancement request to support a better pluggability for OidcClient, I won't be able to prioritize in the short term but may be worth tracking such an enhancement request, thanks

[rkraneis]

Will, do. Unfortunately, improving OidcClient pluggability showed to not be the only missing piece in the puzzle. There's just no way within JAX-RS to modify headers based on the body after the registered MessageBodyWriter (e.g. Jackson) has done its part. So I'm currently serializing the payload twice. I'll have a look at RestEasy reactive client.