Support optional JWT authentication for an endpoint

[ardikabs]

Description:
There is a use case when both authenticated and non-authenticated users can access an endpoint, it would help like when it is intended to apply a rate limit based on the user login, say authenticated users will have a dedicated rate limit threshold compared to non-authenticated users.

For example on integrating optional JWT authentication with rate limit:

1. /api/v1/auth/generate-otp (authenticated): 100 requests per hour per user login
2. /api/v1/auth/generate-otp (non-authenticated): 10 requests per hour per originating IP address

Since our implementation is built upon the specifications outlined in https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto#extensions-filters-http-jwt-authn-v3-jwtrequirement, accomplishing this can be done using the following configuration:

name: envoy.filters.http.jwt_authn
typed_config:
  '@type': type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
  providers:
    provider_example:
      forward: true
      remote_jwks:
        cache_duration: 300s
        http_uri:
          cluster: raw_githubusercontent_com_443
          timeout: 10s
          uri: https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/jwks.json
  requirement_map:
    optional_auth:
      requires_any:
        requirements:
          - provider_name: provider_example
          - allow_missing: {}

Proposal
Therefore in the Envoy Gateway implementation, we can add a new field such as allowMissing to the SecurityPolicy to support this case, like below:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: jwt-example
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: foo
  jwt:
    providers:
    - name: example
      remoteJWKS:
        uri: https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/jwks.json
    allowMissing: true

Luckily, as we already have the requiresAny implementation in the code, integrating it above should be straightforward.

gateway/internal/xds/translator/jwt.go

Lines 168 to 176 in 9416798

	} else {
	orListReqs := &jwtauthnv3.JwtRequirement{
	RequiresType: &jwtauthnv3.JwtRequirement_RequiresAny{
	RequiresAny: &jwtauthnv3.JwtRequirementOrList{
	Requirements: reqs,
	},
	},
	}
	reqMap[route.Name] = orListReqs

[optional Relevant Links:]

Any extra documentation required to understand the issue.

[zhaohuabing]

@ardikabs Thanks for raising this use case! It looks reasonable to me. Let's wait for other @envoyproxy/gateway-maintainers for further insights.

[akevdmeer]

I hope it is acceptable for me to mention #2496 as broadly related. There the feature request is to always require a token, but to either take a JWT bearer token from the Authorization header or if absent initiate the authorization code flow.

[arkodg]

how does optional: true sound as a field name ? (which maps to allow_missing in Envoy)
cc @envoyproxy/gateway-maintainers

[zhaohuabing]

how does optional: true sound as a field name ? (which maps to allow_missing in Envoy) cc @envoyproxy/gateway-maintainers

optional sounds a bit vague to me. It could imply "optional jwt authentication" -- an invalid user token is acceptable, while allowMissing is clear that only missing token is acceptable.

[Alice-Lilith]

optional sounds a bit vague to me. It could imply "optional jwt authentication" -- an invalid user token is acceptable, while allowMissing is clear that only missing token is acceptable.

I don't think it would ever be very common where you would want to allow an invalid token even in the scenario where the token is optional. IMO that sounds like a separate use-case for something like an ignoreMalformed field or something like that.

[zhaohuabing]

@AliceProxy Yes, it's not a legitimate use case. allowMissing simply sounds clearer to me than optional. However, my intuition regarding naming might not be accurate since English is not my native language. :-)