Open qfcgc opened 3 years ago
/cc @geoand
May be quarkus-oidc-client
can help...
@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
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
Definitely sounds like an interesting feature to add
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:
Should we add the quarkus-oidc-client
dependency to quarkus-spring-cloud-config-client
or expect the user will add it?
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 ?
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
Or may be simpler, avoid
quarkus-oidc-client
altogether and use Vert.x client directly from this extension to acquire a token, thoughquarkus-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
I would like to work on this one.
👍🏼
One thing I forgot to mention is that doing it natively in the existing extension would require introducing a good number of new properties:
client_credentials
at the min, or if password
grant is required then a user
and the user secret
would also have to be configuredI'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
I was thinking of adding a OidcCommonConfig
field in the spring config. I contains all properties you mentioned no ?
@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 :-)
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