Support for GRPC

[jotak]

Hi,

Is the proxy supposed to support GRPC? And if not, is it planned / doable?

To add a little bit of context, I'm trying to use grpc between some ossm (service mesh) components, but at this point I wasn't able to have it work with oauth-proxy in the middle.

My oauth-proxy logs seem to indicate the authorization succeeds:

2021/02/10 13:30:42 oauthproxy.go:843: authenticated "internal" via basic auth

But then, the connection fails, client-side showing:

rpc error: code = Unavailable desc = connection closed

Here's the proxy config:

          args:
            - '--cookie-secret=...'
            - '--display-htpasswd-form=false'
            - '--htpasswd-file=/etc/proxy/htpasswd/auth'
            - '--https-address=:8443'
            - >-
              --openshift-sar={"namespace": "istio-system", "resource": "pods",
              "verb": "get"}
            - '--openshift-service-account=jaeger-ui-proxy'
            - '--provider=openshift'
            - '--tls-cert=/etc/tls/private/tls.crt'
            - '--tls-key=/etc/tls/private/tls.key'
            - '--upstream=http://localhost:16686'

If I bypass the proxy to hit directly the jaeger service on port 16686, the connection succeeds.

[stlaz]

OAuth2 flows over a protocol other than HTTP are not very common (or at least I haven't seen a project that would do such a thing, yet the protocol allows it so it is possible).

You seem to have used HTTP basic-auth, so you've practically worked around all the possible merit this proxy provides, so I am not sure you're using the right tool for the job.

That being said, we do not plan on expanding the protocols that are supported by the proxy.

[jotak]

Thanks for your response, Just to understand, is it the reverse-proxy thing (forwarding traffic to upstream) that is too unusual as grpc, or the authorization flow to the oauth server? I'm not asking the oauth flow itself to be over grpc (and actually this part seems to work fine if I believe the logs)

[stlaz]

You bypassed the authorization flow. So it is both that and the reverse-proxy part.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci[bot]]

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/oauth-proxy/issues/205#issuecomment-877851844): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.