E-OAU
OAuth2 Proxy
Reverse proxy that puts OAuth/OIDC login in front of HTTP apps that have none.
OVERVIEW
OAuth2 Proxy sits in front of one or more HTTP upstreams and requires a login through an identity provider — Google, GitHub, Azure, generic OIDC, and others — before traffic is forwarded. Access can be limited by email domain, allow-list file, or IdP group. Config comes from flags, a file, or OAUTH2_PROXY_* environment variables; flags win.
After a successful login the session lives in a cookie (default) or Redis. The proxy can pass identity headers upstream (X-Forwarded-User, email, groups, or a bearer token) or sit behind Nginx/Traefik in auth_request mode and only return a status code. Skip-auth routes, JWT bearer tokens, and trusted IPs exist for APIs and health checks — those same knobs are the first things to review when you find it on an engagement.
USE CASES
Practical use cases
- 01
Putting SSO in front of a lab dashboard or internal app that only speaks HTTP.
- 02
Sitting behind Nginx or Ingress as auth_request so the app never sees unauthenticated traffic.
- 03
Restricting an upstream to one email domain or IdP group instead of a shared password.
- 04
Reviewing a client's oauth2-proxy for skip-auth routes, wildcard email domains, and spoofable forwarded headers.
QUICK START
When an internal app or lab UI has no auth of its own and you need an OIDC gate — or when you find this proxy in front of a target.
- Register an OAuth app with the IdP and set the redirect URL to https://<host>/oauth2/callback.
- Generate a cookie secret (16, 24, or 32 bytes) and keep client id, secret, and cookie secret out of the process list when you can.
- Point --upstream at the app, --email-domain at the org, and listen on 127.0.0.1:4180.
- Run --config-test, then put TLS or Nginx in front — do not expose the listener raw on 0.0.0.0.
oauth2-proxy --provider google --email-domain example.com --upstream http://127.0.0.1:8080/ --http-address 127.0.0.1:4180 --redirect-url https://app.example.com/oauth2/callback --client-id $CLIENT_ID --client-secret $CLIENT_SECRET --cookie-secret $COOKIE_SECRETBEFORE YOU RUN IT
What to check before running it
With --reverse-proxy enabled and --trusted-proxy-ip unset, OAuth2 Proxy currently trusts every source IP for X-Forwarded-* headers — a client that can reach it directly can spoof them.
--email-domain=*, a broad --skip-auth-route, or --trusted-ip is an authentication bypass; treat those as findings when you review a deployment.
--show-debug-on-error can dump sensitive detail on error pages, and --ssl-insecure-skip-verify disables TLS checks to the IdP — neither belongs in production.