Open tareksha opened 3 weeks ago
This is exactly the feature preventing us from adopting Vector as our edge agent. ๐
Perhaps, we can also do another strategy, openid
. The minor change vs. oauth2
is that the HTTP client can discover authentication schemes and endpoints from the standard configuration endpoint.
Perhaps, we can also do another strategy,
openid
. The minor change vs.oauth2
is that the HTTP client can discover authentication schemes and endpoints from the standard configuration endpoint.
@singhbaljit client credentials flow is intended to app-to-app communication in oauth-enabled services. can you explain what a general openid helps here?
Right, client credentials flow is still the primary case. The only difference here is what is configured. With OpenID, we just configure the standard OpenID endpoint; the client can discover/validate token endpoint, supported grant types (client_credentials
and password
), scopes to request.
Right, client credentials flow is still the primary case. The only difference here is what is configured. With OpenID, we just configure the standard OpenID endpoint; the client can discover/validate token endpoint, supported grant types (
client_credentials
andpassword
), scopes to request.
i agree with that. but again we are in app-to-app communication and the requested scopes are expected to be set in the configuration. the discovery aspect does not really give a technical advantage. regarding the token endpoint i can have a rough guess that changing the token endpoint isn't far from changing the discovery endpoint, in practice. i'm finding hard to justify the added complexity of the discovery pre-step.
A few (inter-related) comments:
openid
support is the lowest on my priority list. OpenID is a popular extension of OAuth2. I think it will would nice to have a native support for it. This allows applies to HTTP sources, especially the HTTP Server source. My only reason to bring this up here was to consider OpenID/OAuth2 more holistically, across all HTTP sources/sinks.
A note for the community
Use Cases
Sink data to http services protected with oauth2 client credentials flow. Client ID and secret are available as input, and vector should issue bearer tokens and refresh them continuously during runtime.
Attempted Solutions
Two main solution were evaluated:
We prefer to avoid both because they involve writing ad-hoc components that add a point of failure, plus they are too ad-hoc although oauth2 is an industry standard and it fits very will as a built-in feature in vector.
Proposal
Support a new authentication strategy in http sink configuration:
"oauth2"
auth.strategy
now accepts a third valueoauth2
in addition to the existingbasic
andbearer
.auth.client_id
the oauth2 client ID.auth.client_secret
the oauth2 client secret.auth.token_endpoint
the endpoint for performing auth2 client credentials authentication.auth.token_refresh_grace
a period of time to refresh the token before it expires. for example can default it to 5 minutes.auth.token_client_key
auth.token_client_crt
During runtime: Before data is sent to the http sink target a token is obtained from the endpoint. The obtained token is reused for all subsequent request until it expiration time minus the refresh grace is reached, on which a new token is obtained and the process restarts.
The certificate pair in (6) and (7) might be necessary to support token issuers that require a client certificate.
References
No response
Version
No response