Spring Cloud Config client OpenID Authorization feature request

[qfcgc]

Quarkus 'spring-cloud-config-client' extension only supports username / password authentication. But it is impossible to get properties from Spring Cloud Config server which requires OpenID access token. It would be great for me to see this feature in future releases

[quarkus-bot[bot]]

/cc @geoand

[sberyozkin]

May be quarkus-oidc-client can help...

[qfcgc]

@sberyozkin I asked about this feature on stackoverflow (link: https://stackoverflow.com/questions/67771094/is-there-a-possibility-to-load-properties-from-spring-cloud-config-server-which), @geoand replied: "The extension currently only supports username / password authentication". So I don't think it can be configured using quarkus-oidc-client now. Maybe that extension can be used for getting access token before request to Spring Config Server

[sberyozkin]

Maybe that extension can be used for getting access token before request to Spring Config Server

Yes, this is what quarkus-oidc-client is used for, quarkus-oidc-reactive-client-filter/quarkus-oidc-client-filter can be used to transparently set the token

[geoand]

Definitely sounds like an interesting feature to add

[glefloch]

I would like to work on this one. If I understand correctly, we would update spring-cloud-config-client to add the Bearer token as header:

https://github.com/quarkusio/quarkus/blob/577f3ac64974b382efd77a345041b1178dd6fe60/extensions/spring-cloud-config-client/runtime/src/main/java/io/quarkus/spring/cloud/config/client/runtime/VertxSpringCloudConfigGateway.java#L185

Should we add the quarkus-oidc-client dependency to quarkus-spring-cloud-config-client or expect the user will add it?

[sberyozkin]

May be that code should be encapsulated in a default SpringCloudClientCredentialsProvider ? And then a new spring-cloud-config-client-oidc extension would only depend on quarkus-oidc-client and provide SpringCloudClientCredentialsProvider implementation which would set Authorization: Bearer token ?

Does it sound reasonable ?

[sberyozkin]

Or may be simpler, avoid quarkus-oidc-client altogether and use Vert.x client directly from this extension to acquire a token, though quarkus-oidc-client is quite flexible. Not really sure which option is best

[geoand]

Or may be simpler, avoid quarkus-oidc-client altogether and use Vert.x client directly from this extension to acquire a token, though quarkus-oidc-client is quite flexible. Not really sure which option is best

I think this option is probably the best. I don't think we need to make things complicated for this use case

[geoand]

I would like to work on this one.

👍🏼

[sberyozkin]

One thing I forgot to mention is that doing it natively in the existing extension would require introducing a good number of new properties:

• OIDC provider token URL (or just in case of Keycloak - its realm endpoint and the token endpoint would be auto-discovered - since the token URL may not be directly doc-ed in the provider docs)
• client-id
• client-secret (at the min id/secret would be posted as Basic credentials - but for the service accounts the JWT authentication is typical - this would require using a client secret or separately configured private key to create a JWT token in order to authenticate to OIDC provider to get the access token)
• choice of the grant type client_credentials at the min, or if password grant is required then a user and the user secret would also have to be configured
• refreshing the token once it expires

I've typed it and I guess I'd recommend using quarkus-oidc-client after all since it is taking care of all the above issues. But it is fine if the native approach is preferred as well

[glefloch]

I was thinking of adding a OidcCommonConfig field in the spring config. I contains all properties you mentioned no ?

[sberyozkin]

@glefloch OidcClientConfig has grant.type as well (may be it is always a single and the same grant type for acquiring the token for Spring Cloud Config so may be it is not needed). If it will be added to the spring config extension then you'd end up re-implementing a good portion of quarkus-oidc-client, hence the first option I suggested earlier seems to be a much easier option to me after all :-), you'd just have a configured OidcClient injected into a custom credentials provider and use it to get a token, auto-refreshed if needed - without bringing all the quarkus-oidc-common dependencies into the current extension.

But I may be biased :-)