skip-auth-preflight doesn't work with auth_request/forwardAuth sub-requests

[andytson]

Expected Behavior

When using skip-auth-preflight with oauth2-proxy behind Nginx or Traefik and auth_request/forwardAuth sub-requests are used, OPTIONS requests to the ingress should be allowed

Current Behavior

It's blocked because the check in oauth2-proxy just checks it's own request (which is a sub-request) method

Possible Solution

oauth2-proxy should use X-Original-Method/X-Forwarded-Method for the preflight check when in reverse proxy mode.

Steps to Reproduce (for bugs)

1. Implement config with skip-auth-preflight and reverse-proxy set
2. Implement a k8s ingress that has the annotations/middleware for an auth request to oauth2-proxy
3. curl -X OPTIONS http://the-ingress-host
4. Receive a unexpected 401 or 302 depending on oauth2-proxy endpoint used and middleware usage

Context

This prevents the OPTIONS request succeeding, which doesn't receive cookie credentials.

Your Environment

• Version used: 7.2.1
• Kubernetes
• Nginx or Traefik ingress controller
• Ingress with annotations/middleware for the auth request

[andytson]

I assume this is also an issue by the looks of things for the allowed routes functionality as well, as it seems to refer only to the own request as well.

The TrustedIps I've not had this problem with

[andytson]

I'm wondering about the implementation for the fix.

Though I could just do a check for X-Fowarded-Method and use if there only if reverse-proxy mode.

[andytson]

Just to update, ingress-nginx k8s controller sets up X-Original-Method instead of X-Fowarded-Method. It seems dangerous to choose one or the other without knowledge of which is correct, if a client can fake the other header and bypass on other methods

[JoelSpeed]

It seems dangerous to choose one or the other without knowledge of which is correct, if a client can fake the other header and bypass on other methods

In general, we have left the reverse-proxy as a more insecure option where we recommend that users filter out headers before making the subrequest (Nginx may already do some of this by default), so I think working on both could be allowed based on the reverse-proxy flag, but the alternative is to have configuration for this to allow users to choose which value to use

[andytson-inviqa]

I'm currently solving this issue targeting the specific ingress that needs preflight in k8s with ingress-nginx via:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-snippet: |
      if ($request_method = OPTIONS) {
        return 200;
      }

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[kartoch]

I can confirm this behavior is still present in v7.4.0.

At the present time, the traefik way to handle it is to create two rules:

    # Expose API for preflight requests
    - kind: Rule
      match: Host(`api.tralala.com`) && Method(`OPTIONS`)
      priority: 200
      services:
        - name: tralala-svc
          port: 5000
    # Expose API with authentication
    - kind: Rule
      match: Host(`api.tralala.com`)
      priority: 100
      middlewares:
      - name: api-oauth2-proxy # middleware ForwardAuth
      services:
        - name: tralala-svc
          port: 5000