The NGINX Ingress Controller was retired in March 2026. Many teams running Amazon Elastic Kubernetes Service (Amazon EKS) have already started migrating to the AWS Load Balancer Controller, a fully AWS native solution that provisions Application Load Balancers (ALBs) directly from Kubernetes Ingress resources. The AWS guide Navigating the NGINX Ingress retirement: a practical guide to migration on AWS covers the core migration: the controller comparison, URI rewriting, and TLS termination.
This post covers the one area that guide intentionally left out: preserving your OpenID Connect (OIDC) authentication flow when oauth2-proxy is in the request path. For teams already running oauth2-proxy with NGINX for OIDC authentication (such as Keycloak and Okta), this migration raises a key question: how do I keep my authentication flow working with ALB? One trade-off to understand upfront: Solution 2 changes the header your backend receives. The ALB forwards the token in x-amzn-oidc-accesstoken , not the standard Authorization: Bearer header that oauth2-proxy sends.
If your application expects the standard header, this is a subtle breaking change you will need to handle (covered in Solution 2). Solution 1 preserves the Authorization: Bearer header your backend already expects. The right choice depends on your requirements around token handling, the number of components you want to run, and whether your backend can accept a different header. Use this decision framework: In short: choose Solution 1 for the least disruption and no backend changes. Choose Solution 2 to remove oauth2-proxy when your backend can adapt to ALB’s headers.
Most NGINX + oauth2-proxy setups use auth subrequests , an NGINX-specific feature where NGINX validates every incoming request against oauth2-proxy before forwarding to the backend: The ALB can’t perform subrequests. When you switch from ingressClassName: nginx to ingressClassName: alb , these annotations are silently ignored and traffic flows to the backend without authentication. Both solutions that follow address this. Keep oauth2-proxy in your architecture but switch it from auth-subrequest mode (where NGINX called it) to reverse proxy mode (where it receives all traffic directly from the ALB).