Support OAuth2 for analysis provider

[OpenGuidou]

Hello,

If we use OAuth 2 as authentication for a provider, there is currently no way to execute the small logic to get an access token before running the analysis.

Do you think it would be a valid improvement to support that ?

In the PrometheusMetric, we have available an Authentication for AWS sigv4.
It could be enhanced to support also OAuth2 protocol.

I would propose the following structure:

For Prometheus:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: args-example
spec:
  args:
  - name: service-name
  - name: api-url
    value: http://example/measure
  # from secret
  - name: oauthSecret
    valueFrom:
      secretKeyRef:
        name: oauth-secret
        key: secret
provider:
      prometheus:
        address: "{{ args.api-url }}"
        authentication:
          type: oauth2
          url: https://myoauthprovider
          clientId: someid
          secret: "{{ args.oauthSecret }}" 
        query: |
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m]
          )) /
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m]
          ))

Also available for web:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: args-example
spec:
  args:
  - name: service-name
  - name: api-url
    value: http://example/measure
  # from secret
  - name: oauthSecret
    valueFrom:
      secretKeyRef:
        name: oauth-secret
        key: secret
    provider:
      web:
        url: "{{ args.api-url }}?service={{ args.service-name }}"
        timeoutSeconds: 20 # defaults to 10 seconds
        authentication:
          type: oauth2
          url: https://myoauthprovider
          clientId: someid
          secret: "{{ args.oauthSecret }}" 
        jsonPath: "{$.data.ok}"

The OAuth authorization would be run before the analysis actual run, and the "Authorization: Bearer " header would be appended to the actual api call (prom or web) with the access_token resolved.

Thanks

[zachaller]

You could create a new metrics provider plugin with code for your particular oauth provider

[OpenGuidou]

Yes indeed I thought about using plugins for that, but in the end it doesn't seem to be the right approach as:

• A big chunk of the existing provider logic would need to be coded again in the plugin, as the current provider interfaces are not allowing to pass the custom client or transport information. This would induce extra maintenance cost to keep the plugin in sync with new developments occurring in the "main" providers.
• The authentication structure is already created and supports AWS SIGV4, so I think it would make sense to support multiple authentication flavors there

Can I open a PR with the suggested changes, so that you can assess the simplicity of the integration, and we can discuss further about it ?

[zachaller]

The main issue I think I have is all the small difference that every oauth provider has you can look a the dex project as an example where you have to deal with difference in how say azure vs ping vs octa behaves cover all those use cases in tree becomes a burden in it's own right and is also impossible to test as maintainers (aka we would need azure accounts etc).

I am also worried about the slippery slope as well in all the different flows of oauth do you support (client credentials, implicit *deprecated, on behalf of, auth code with PKCE, etc etc). Maybe this is over thinking but I do think it's something to also consider.

I think any system designed should be aware of all the providers and their unique requirements.

[OpenGuidou]

I would propose to be as generic as possible, and only implement the client-credentials flow (which is the only one that makes sense in an automated app flow) and using the corresponding lib: https://pkg.go.dev/golang.org/x/oauth2/clientcredentials that should work for all.

[OpenGuidou]

Closed with #3038