oauth2-proxy

What is oauth2-proxy?

The oauth2-proxy image packages oauth2-proxy, a widely-used open-source reverse proxy that adds authentication and authorization enforcement in front of any web application or internal service without requiring changes to the application itself. oauth2-proxy intercepts inbound requests, redirects unauthenticated users through an OAuth 2.0 or OIDC login flow with a configured identity provider — Google Workspace, GitHub, Azure AD, Okta, Keycloak, GitLab, and many others — and only forwards requests to the upstream once the user has a valid session. It validates tokens, manages session cookies, supports email domain and group-based access restrictions, and can pass authenticated user identity downstream via headers so upstream services know who is making the request. oauth2-proxy is used by platform and infrastructure teams to add authentication to internal dashboards, developer tools, and back-office services that have no built-in auth — Kubernetes dashboards, Grafana instances, Prometheus UIs, internal APIs, and staging environments are common use cases. It is also deployed as the authentication layer in zero-trust architectures where every internal service requires identity verification regardless of network position, and as a lightweight alternative to a full identity-aware proxy for teams that don't need the full feature set of solutions like Google BeyondCorp or Cloudflare Access.

What is Echo's oauth2-proxy image?

Echo's oauth2-proxy image is a hardened build of oauth2-proxy on Echo's hardened base. Echo images are designed to be a drop-in replacement: swap the image reference in your oauth2-proxy deployment manifest or ingress configuration and CVEs go to zero without disrupting your provider configuration, session management, or upstream routing. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants:

• Distroless variant — optimized for runtime use, with the smallest possible attack surface
• Default variant — includes essential build tools, package managers, and shells for teams that need operational access

For production oauth2-proxy deployments, the distroless variant keeps all proxy operations — OIDC token validation, session cookie management, provider redirect flows, email and group-based access enforcement, and upstream request forwarding — fully intact while minimizing exposure; the default variant suits platform teams that need shell access for configuration debugging, provider callback troubleshooting, or inspecting session and cookie behavior at runtime.

What is the difference between Echo's oauth2-proxy image and the public oauth2-proxy image?

Public oauth2-proxy images ship on bases that include OS-level tooling convenient for development but which contribute CVEs that accumulate on a proxy running continuously in production as the authentication boundary for your internal services. Authentication proxies occupy the most sensitive position in your perimeter — oauth2-proxy is the gatekeeper between the public internet and your internal tools, holding the client secret used to authenticate with your identity provider, managing session tokens for every user accessing protected services, and making the trust decision that determines whether a request reaches your upstream or not. A vulnerability in the base image doesn't just expose the proxy process; it can be used to forge or hijack sessions, extract the OAuth client secret to impersonate the application with your identity provider, bypass access controls entirely, or silently forward traffic to upstreams that should be protected. The authentication layer is exactly the component that attackers target first — and a compromised auth proxy means every service behind it is compromised too. Echo's build retains everything oauth2-proxy needs for OIDC token validation, session management, provider redirect handling, and upstream forwarding while removing the packages that don't belong in a production authentication proxy. As we covered in our post on how to protect your company from software supply chain attacks, the components that make trust decisions in your infrastructure are the highest-value targets in a supply chain attack — compromising them silently invalidates every other security control downstream. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my oauth2-proxy image with Echo's oauth2-proxy image?

Yes. Echo's oauth2-proxy image is a drop-in replacement. Update the image reference in your deployment manifest, Helm values, or ingress annotation and your authentication proxy keeps running. OIDC provider configuration, session cookie management, email domain and group-based access restrictions, upstream routing, and identity header injection all continue to work without any changes to your existing oauth2-proxy flags, environment variables, or provider callback URLs.

Is Echo's oauth2-proxy image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for platform teams running oauth2-proxy inside FedRAMP boundaries where a proxy that validates OIDC tokens, manages encrypted session cookies, and authenticates to identity providers over TLS must meet cryptographic requirements at every layer — not just in the identity provider itself.

What is Echo's vulnerability management SLA on the oauth2-proxy image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for an authentication proxy that runs continuously as the trust boundary for your internal services, holds your OAuth client secret, and manages active sessions for every user accessing protected infrastructure.

Is Echo's oauth2-proxy image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production oauth2-proxy deployments where the proxy runs as a long-lived authentication boundary, the distroless variant is the leaner, more secure choice; for platform teams that need shell access for provider callback debugging, cookie and session inspection, or configuration validation, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in oauth2-proxy?

Echo's oauth2-proxy image is built from source with only the absolute essentials needed to run the authentication proxy workload, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the oauth2-proxy version your provider configuration and ingress setup are built against without forcing a disruptive upgrade that risks breaking callback URLs, session behavior, or access restriction rules across your protected services.

Will Echo's oauth2-proxy image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For platform teams running oauth2-proxy as the authentication layer for internal tooling and services under an ATO, Echo's hardened oauth2-proxy image keeps the trust boundary in-boundary and compliant without requiring custom hardening or manual patching between compliance cycles.