@arkodg any comments to this one? As I see this is quite important feature to have possibility to use service with human users and machines.

@zetaab @sadovnikov my hesitance is with including another field like matches within oidc . Today the request is matching header attributes defined within the HTTPRoute and the SecurityPolicy is applied to a HTTPRoute. Adding another matches within oidc is not required and may confuse the user.

You could implement the same logic (#2425 (reply in thread)) with 2 HTTPRoutes today

• Security Policy 1 with a oidc config that applies to a HTTPRoute1 which has your routing rules
• Security Policy 2 with a jwt config that applies to a HTTPRoute2 which has your routing rules along with extra matches such as BearerToken is set && OauthHMAC is empty && OauthExpires is empty (will take precedence to the extra matches)

This should unblock you for now, but will end up causing some duplicate configuration for you.

You could also use a EnvoyPatchPolicy with a pass_through_matcher defined in https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/oauth2/v3/oauth.proto#extensions-filters-http-oauth2-v3-oauth2config

A more long term would be to to figure out the right UX / field for this use case.

@arkodg From my discussion with @zhaohuabing I understood that two HTTP Routes cannot be applied to the same host/path. It seems I read it wrong, it's just necessary to ensure the uniqueness of the "matches" in the routes. We'll give it a try

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

here is the example of how it can be used currently https://gist.github.com/zetaab/31b835bfed5bdc7b2a3e29bc6557e3c1

What that does?

• it can have public paths which is allowed to everyone
• it have /login path which will make the OIDC flow for humans and create cookies
• /api path which will work for both: humans (with cookie) and machines (with bearer token) (with two different identity providers)

However, if its used like this it means that application should have the logic to redirect to /login when its needed to use refresh token / create new token.

tl;dr it works but its not pretty

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

rethinking this one, if we add introduce a field - skipIfJWTExists, we can solve this, we may also need to then add another field myJWTLivesInThisHeader

Yeah, this sounds reasonable to me. I'll raise an issue in Envoy and try to support this in v1.3.0.

@zhaohuabing envoy already supports this as highlighted in #2496 (comment)

An API field is needed in EG that solves the use case

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

It looks like the pass_through_matcher option in Envoy's oauth2 filter can be used to make this work.

https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/oauth2/v3/oauth.proto#envoy-v3-api-msg-extensions-filters-http-oauth2-v3-oauth2

I've tried the following patch and it appears to be working.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
metadata:
  name: oidc-and-jwt-patch
  namespace: example
spec:
  jsonPatches:
    - name: example/eg/https
      operation:
        op: add
        path: >-
          /filter_chains/0/filters/0/typed_config/http_filters/0/typed_config/config/pass_through_matcher
        value:
          - name: Authorization
            prefix_match: Bearer
      type: type.googleapis.com/envoy.config.listener.v3.Listener
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  type: JSONPatch

I guess the fix for this issue is to change the xds translator so that if jwt auth is also specified in the gateway CRD then pass_through_matcher is added to the xDS.

It would be nice if oidc and basic auth also worked well together. In this case the logic would need extending to pass through when "Authorization: Basic...." is in the headers, but the default filter order would also need changing to put the basic auth filter after oidc.

Edit: scratch that last bit about basic auth... clearly not going to work

hey @StephenRobin thanks for driving this work
we'll need an API field to opt into this functionality (ref to #2496 (comment) )

Hi @arkodg, I'm not so sure that a new field makes sense.

This was my thinking:

1. Would there ever be a situation where you would have OIDC enabled and JWT enabled and want newField=false? I can't think of one, JWT is broken without it.
2. Would there ever be a situation where you have only OIDC enabled and want newField=true? I can't think of one, OIDC is insecure in this case.
3. Why put the new field on OIDC? It feels rather arbitrary, it could equally go on JWT. Its purpose is to make the two work well together.

Therefore it made more sense to just automatically allow oidc bypass when jwt is also enabled.

Thinking about it again, this might be the wrong behaviour if they had either changed the order of the filters, or if they were using the extractFrom feature in JWT.

Thanks for thinking this through @StephenRobin

Would there ever be a situation where you would have OIDC enabled and JWT enabled and want newField=false? I can't think of one, JWT is broken without it.

There may be a case, when a user may want to force OIDC Auth.

@missBerg @zhaohuabing @denniskniep probably have a better understanding of the spec, but I think there's a chance we may want to implicitly add JWT validation in the future if the spec clearly mentions it, this would mean that a separate JWT instantiation is not required.

Would there ever be a situation where you have only OIDC enabled and want newField=true? I can't think of one, OIDC is insecure in this case.

yes, this is something that can be flagged with a bad status Accepted=False for the SecurityPolicy which should also block the route (EG adds a 500 direct response for this case) .

Why put the new field on OIDC? It feels rather arbitrary, it could equally go on JWT. Its purpose is to make the two work well together.

It pertains to skipping OIDC Auth, so imo should live in OIDC.

Thinking about it again, this might be the wrong behaviour if they had either changed the order of the filters, or if they were using the extractFrom feature in JWT.

We can make this intelligent and peek into extractFrom and use that to define the skip condition