OAuth2 Proxy is an open-source, MIT-licensed reverse proxy and middleware written in Go that puts OAuth2 and OpenID Connect authentication in front of web applications, aimed at operators and platform teams who need single sign-on without adding auth code to every app.

What it is

OAuth2 Proxy is a flexible, open-source tool that can act either as a standalone reverse proxy or as a middleware component integrated into existing reverse proxy and load balancer setups. It lives in the Go and cloud-infrastructure ecosystem, where it occupies the layer between an incoming HTTP request and the upstream application, handling authentication on behalf of that application. The project supports a large number of OAuth2 and OIDC providers, working either through a generic OIDC client or through specific implementations for Google, Microsoft Entra ID, GitHub, login.gov and others.

The concrete problem it solves is auth for applications that have none of their own. As a reverse proxy, it intercepts requests to the application and redirects users to an OAuth2 provider for authentication; as middleware, it can be integrated into existing infrastructure to handle authentication for multiple applications at once. That means it replaces per-application login code and bespoke session handling with one shared proxy that speaks the standard protocols. Through specialised provider implementations it also extracts more detail about the user, such as preferred usernames and groups, and forwards those details to upstream applications as HTTP headers.

Key capabilities

• Runs in standalone reverse proxy mode, intercepting requests and redirecting users to an OAuth2 provider for authentication.
• Runs as middleware inside an existing reverse proxy or load balancer, handling authentication for multiple applications from one deployment.
• Supports many OAuth2 and OIDC providers through a generic OIDC client plus specific implementations for Google, Microsoft Entra ID, GitHub, login.gov and others.
• Extracts preferred usernames and groups through specialised provider implementations and forwards them as HTTP headers to upstream applications.
• Publishes compiled binaries on GitHub for all major architectures, including ppc64le and s390x.
• Ships container images built on GoogleContainerTools/distroless from v7.6.0 onward, with -alpine suffixed tags for debugging and armv6.
• Publishes nightly images from the master branch at quay.io/oauth2-proxy/oauth2-proxy-nightly.

Who uses it and how

• Teams that already run a reverse proxy or load balancer and want to add authentication as middleware rather than change each application.
• Platform operators exposing several internal applications behind one proxy and one identity provider, using the generic OIDC client to avoid per-app wiring.
• Deployments on less common hardware, where the ppc64le and s390x binaries or the -alpine images for armv6 are the practical route.
• Security-focused environments that adopt the distroless base image specifically to reduce installed dependencies in the container.
• Contributors and integrators: the project carries the hacktoberfest topic, runs a Slack channel, and is sponsored by the SAP Open Source Program, with Microsoft Azure credits listed as a former sponsor.

Getting started

Installation and configuration are covered by the project's installation docs at http://oauth2-proxy.github.io/oauth2-proxy/, which point to example setup files in contrib/local-environment. Ready-made options are compiled binaries from GitHub releases, container images from the published registry, or nightly builds at quay.io/oauth2-proxy/oauth2-proxy-nightly.

How it compares

No comparable projects are named in the material available for this entry, and no list of paid products it replaces is provided. On the facts given, it stands alone in this registry.

When to use it — and when not to

A self-hoster must run and configure the proxy itself, register an OAuth2 or OIDC client with an external identity provider, and manage TLS termination for the endpoints it fronts, since the project has no user directory of its own and depends entirely on that external provider. It is a poor fit for anyone who wants authentication without operating extra infrastructure or who needs managed auth as a service. Two honest caveats: the nightly images are explicitly unstable and should not be used in production unless the operator knows what they are doing, and with 285 open issues the tracker is busy, so checking recent activity before committing is sensible.