Support OIDC based authentication

[arkodg]

Description:
Support OIDC based authentication

Support in envoy

• https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/oauth2_filter.html
• Do we have any plans to support OIDC? envoy#21982

Relates to #336

[lizan]

The Envoy oauth2 filter isn't really an OIDC authentication filter but issuing some custom custom format token in cookies/headers. We might want to look at some control plane for this like vouch-proxy

[arkodg]

hey @lizan assigning this issue to you since you're looking into it, please feel to unassign if anything changes

[arkodg]

@lizan do you think a new filter can be added to envoyproxy or the current oauth filter can be extended to support the OIDC flow (potentially including redirects, and an external storage backend [Redis] for server tokens) .
This would eliminate the need to achieve the same using an external service such as https://github.com/istio-ecosystem/authservice

cc @mattklein123 @ZackButcher

[lizan]

Yes that is also doable. It is likely we need to do a new filter for OIDC. We just need to agree on a plan to support what flow and how to configure token storage etc. If that's more desired for EG community we can do that. Let's compare which path is better

[mattklein123]

Yes that is also doable. It is likely we need to do a new filter for OIDC. We just need to agree on a plan to support what flow and how to configure token storage etc. If that's more desired for EG community we can do that. Let's compare which path is better

Can we put together a short design doc on the options of sharing the filter vs. a new filter? I would imagine a lot of the logic will be shared. Perhaps there can be a common core shared between the 2 filters. I don't know enough details to know if that makes sense or not but we should see so we don't end up with substantial code duplication for a security critical feature.

[lizan]

My bad I meant the opposite we shouldn't need a new filter for OIDC. The existing oauth filter can do a very basic flow of OIDC already.

For OIDC Discovery I don't think it should should be done in Envoy directly but should be a responsibility of control plane.

[arkodg]

hey @lizan any update ?

[lizan]

I've been testing several scenarios with oauth2 filter and looks like it can be used for OIDC authentication, so we don't need additional control plane for now. Will send a PR for API review soon.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[sujeshkumar]

I've been testing several scenarios with oauth2 filter and looks like it can be used for OIDC authentication, so we don't need additional control plane for now. Will send a PR for API review soon.

@lizan are these PRs already merged ? is there any plan to use wellknownUrls to get information like auth_endpoint / token_endpoint etc ?

[arkodg]

hey @lizan unassigning you since you mentioned you are no longer working on this.
would help the next contributor if you attached any past work to this issue, TIA !

[arkodg]

attaching a relevant article that has the filter config https://www.jpmorgan.com/technology/technology-blog/protecting-web-applications-via-envoy-oauth2-filter

[tmsnan]

Hi, I can work on this function, please assign it to me if no one else is working on it.

[zhaohuabing]

@tmsnan I already have a design doc and API drafted on this which I'll share soon. Would love to work with you if you're also interested in it.

[zhaohuabing]

Design: https://docs.google.com/document/d/1qowAZz0fID8KsW5TlAF6ZSVb5qhgpP3QMlsM6yVVMgs
POC demo: https://github.com/zhaohuabing/playground/tree/main/envoy/external-auth-oidc

@tmsnan @zirain @arkodg

[zhaohuabing]

We have 4 options for the API, which are described in detail in the design.

I suggest we start with option 2 since this strategy has already been taken by JWT authentication and is compatible with the current AuthenticationFilter API. We can start with option 2, collect feedback from users, and then evolve according.

Option 2. Authentication at route level
Model OIDCAuthentication as a new OIDC AuthenticationFilter type.

Example config:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: AuthenticationFilter
metadata:
  name: google
spec:
  type: OIDC
  oidcAuthentication:
    provider:
      issuer: "https://accounts.google.com"
      authorizationEndpoint: "https://accounts.google.com/o/oauth2/v2/auth"
      tokenEndpoint: "https://oauth2.googleapis.com/token"
      jwks: xxxxxxxxxxxxxx
    clientId: xxxxxxxxxxx
    clientSecret: client-secret
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: backend
spec:
  parentRefs:
  - name: eg
  hostnames:
  - "www.example.com"
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: backend
      port: 3000
      weight: 1
    filters:
    - extensionRef:
        group: gateway.envoyproxy.io
        kind: AuthenticationFilter
        name: google
      type: ExtensionRef
    matches:
    - path:
        type: PathPrefix
        value: /foo

[Xunzhuo]

Close by #2122