Is it possible for APISIX’s OIDC plugin to manage groups? if not, can I do it oauth2-proxy to secure my application?

[sopacifics]

Authentication/Authorization Flow (in case that it is not possible only with OIDC)

nitial Request:

• Client sends request to APISIX

OIDC Authentication:

• APISIX OIDC plugin checks if the user is authenticated
• If not authenticated, APISIX redirects to your OIDC provider
• User authenticates with the OIDC provider
• OIDC provider redirects back to APISIX with authorization code
• APISIX exchanges code for tokens and validates them

Group-based Authorization:

• After successful OIDC authentication, APISIX forwards the request to oauth2-proxy
• APISIX includes the ID token or access token in the request header
• oauth2-proxy extracts the token and validates group membership claims
• oauth2-proxy applies the group filter logic to determine authorization

Access Decision:

• If the user belongs to an authorized group, oauth2-proxy forwards the request back to APISIX
• If not authorized, oauth2-proxy returns a 403 Forbidden response

Backend Access:

• APISIX receives the authorized request from oauth2-proxy
• APISIX proxies the request to the backend application

[dosubot[bot]]

The APISIX OIDC plugin does not natively support managing group membership claims. However, you can use oauth2-proxy to handle group-based authorization after successful OIDC authentication with APISIX.

In your described flow, after APISIX completes the OIDC authentication, it can forward the request to oauth2-proxy with the ID token or access token included in the request header. oauth2-proxy can then extract the token, validate the group membership claims, and apply the necessary group filter logic to determine if the user is authorized. If the user is part of an authorized group, oauth2-proxy forwards the request back to APISIX, which then proxies it to the backend application.

This setup allows you to leverage oauth2-proxy for group-based authorization while using APISIX for OIDC authentication.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[sopacifics]

Thank you so much, is there any example I can follow to allow this? in advance, thanks.

[Baoyuantop]

No examples found, feel free to share problems encountered during implementation

[sopacifics]

Hi @Baoyuantop @dosu,

We're running into an issue with our APISIX configuration that we hope you can help with.

Our setup:

We're trying to combine a global OIDC plugin + auth2-proxy. Our goal is that, after a successful OIDC authentication, APISIX should forward the request to oauth2-proxy, include the access token in the request headers, and then redirect to the oauth2-proxy callback URL. However, when we implement the following configuration, oauth2-proxy returns a 500 error:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: example
  namespace: example
spec:
  http:
    - name: protected-services
      match:
        hosts:
          - example.com
        paths:
          - /api
          - /
      filter:
        vars:
          - ["uri", "regex", "^/api(/|$)(.*)"]
      backends:
        - serviceName: SERVICE_NAME
          servicePort: PORT
      plugins:
        - name: openid-connect
          enable: true
          config:
            client_id: "CLIENT_ID"                                
            client_secret: "CLIENT_SECRET" 
            discovery: ".../.well-known/openid-configuration"
            redirect_uri: "https://oauth2-proxy.../oauth2/callback"
            scope: "SCOPE"
            bearer_only: false
            session:
              secret: ""
              cookie:
                secure: true
                httponly: true
        - name: proxy-rewrite
          config:
            headers:
              Authorization: "Bearer $session_jwt"
              X-Auth-Request-User: $jwt_claim_sub
              X-Auth-Request-Email: $jwt_claim_email
              X-Auth-Request-Groups: $jwt_claim_groups

Observed behavior:

• After OIDC authentication, APISIX correctly forwards the request to oauth2-proxy.
• APISIX adds the access token to the request header.
• However, it then redirects to the oauth2-proxy callback URL, and oauth2-proxy returns a 500 error.

When we bypass APISIX+OIDC and use oauth2-proxy directly via an Ingress (see configuration below), everything works as expected:

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"nginx.ingress.kubernetes.io/auth-response-headers":"Authorization,X-Auth-Request-User,X-Auth-Request-Email,X-Auth-Request-Groups","nginx.ingress.kubernetes.io/auth-signin":"https://oauth2-proxy...oauth2/start?rd=$scheme://$best_http_host$request_uri","nginx.ingress.kubernetes.io/auth-url":"http://oauth2-proxy....local:80/oauth2/auth","nginx.ingress.kubernetes.io/proxy-buffer-size":"128k","nginx.ingress.kubernetes.io/proxy-busy-buffers-size":"128k","nginx.ingress.kubernetes.io/proxy-read-timeout":"300","nginx.ingress.kubernetes.io/proxy-send-timeout":"300","nginx.ingress.kubernetes.io/use-regex":"true"},"labels":{"app.kubernetes.io/instance":"renewals-risk-ui"},"name":"renewals-risk-ui-ingress","namespace":"console-ui"},"spec":{"ingressClassName":"nginx","rules":[{"host":"cxassistant-dev.cisco.com","http":{"paths":[{"backend":{"service":{"name":"renewals-risk-questions-api","port":{"number":8090}}},"path":"/api(/|$)(.*)","pathType":"ImplementationSpecific"},{"backend":{"service":{"name":"example","port":{"number":8090}}},"path":"/","pathType":"Prefix"},{"backend":{"service":{"name":"oauth2-proxy","port":{"number":80}}},"path":"/oauth2(/|$)(.*)","pathType":"ImplementationSpecific"}]}}],"tls":[{"hosts":["example.com"],"secretName":"cert-secret"}]}}
    nginx.ingress.kubernetes.io/auth-response-headers: Authorization,X-Auth-Request-User,X-Auth-Request-Email,X-Auth-Request-Groups
    nginx.ingress.kubernetes.io/auth-signin: https://oauth2-proxy..../oauth2/start?rd=$scheme://$best_http_host$request_uri
    nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy....local:80/oauth2/auth
    nginx.ingress.kubernetes.io/proxy-buffer-size: 128k
    nginx.ingress.kubernetes.io/proxy-busy-buffers-size: 128k
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
    nginx.ingress.kubernetes.io/use-regex: "true"
  creationTimestamp: "2025-01-24T22:00:31Z"
  generation: 13
  labels:
    app.kubernetes.io/instance: example
  name: example
  namespace: example
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          service:
            name: example
            port:
              number: 8090
        path: /
        pathType: Prefix
      - backend:
          service:
            name: oauth2-proxy
            port:
              number: 80
        path: /oauth2(/|$)(.*)
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - example.com
    secretName: cert-secret

Could the issue be related to how the headers are sent by the OIDC plugin doesn't match what oauth2-proxy is expecting? is there any why to modify that header in APISIX?

Thank you so much for your help in advance!

Best regards,
Sofia

[sopacifics]

We resolved the issue using APISIX forward-auth plugin and serverless-post-function plugin intercepts authentication failures and redirects users to the OAuth login page.

Authentication Flow

1. Client sends request to an API endpoint protected by this configuration
2. APISIX forwards authentication data to the OAuth2 proxy service
   If authentication is valid:

• OAuth2 proxy returns a successful response
• APISIX forwards the original request to the upstream service
• Authentication details are passed via headers to upstream services

3. If authentication fails (401 or 403):

• The serverless-post-function intercepts the error
• A redirect to the OAuth2 login page is generated
• The client browser is redirected to authenticate
• After successful authentication, the user is returned to their original request URL

[dosubot[bot]]

To address the issue with the 500 error from oauth2-proxy, you can modify the headers in APISIX using the proxy-rewrite plugin. This plugin allows you to set, add, or remove headers to ensure compatibility with oauth2-proxy. Here's how you can configure it:

1. Modify Headers with proxy-rewrite: Ensure that the headers being sent match what oauth2-proxy expects. You can adjust the headers using the proxy-rewrite plugin configuration.

   Example configuration:

   plugins:
     - name: proxy-rewrite
       config:
         headers:
           set:
             Authorization: "Bearer $session_jwt"
             X-Auth-Request-User: $jwt_claim_sub
             X-Auth-Request-Email: $jwt_claim_email
             X-Auth-Request-Groups: $jwt_claim_groups

2. Check Header Requirements: Verify that the headers you are setting align with the expected format and names required by oauth2-proxy. If oauth2-proxy expects specific headers or formats, ensure they are correctly configured in the proxy-rewrite plugin.

3. Diagnose the 500 Error: Common causes of a 500 error include misconfigured headers or missing required headers. Ensure that all necessary headers are included and correctly formatted. You can also check the oauth2-proxy logs for more detailed error messages that might indicate what is causing the 500 error.

By ensuring that the headers are correctly set and match what oauth2-proxy expects, you should be able to resolve the 500 error. If the issue persists, reviewing the logs for specific error messages can provide further insights into the problem.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}