Skip to main content
Change Risk Intel
Tools & Comparisons

Auth Gateways Compared: oauth2-proxy, Authelia, Pomerium

Ben Ennis Founder, Ennis Studio · former Partner Technology Advisor, ServiceNow · 11 min read

This comparison contains no affiliate links. All capability claims are drawn from each project’s own public documentation, linked in Sources.

Table of contents

Why this matters

Every organization runs internal tools that never shipped with single sign-on: a Grafana instance, a self-hosted BI dashboard, an admin panel, a legacy ticketing app. Left alone, these end up behind a shared password, a VPN, or nothing at all. A reverse-proxy auth gateway solves that by forcing every request through an identity check before it reaches the app — no code change to the app itself.

For a change advisory board, the choice is not academic. The gateway becomes a control point that shows up in your access reviews, your SOC 2 evidence, and your incident blast radius. Picking the wrong one means either an under-protected app or a gateway that becomes its own single point of failure. This comparison looks at four widely deployed options and names a real weakness of each, so the decision survives a security review rather than just a demo.

The same week this published, CISA added an F5 BIG-IP APM flaw to its Known Exploited Vulnerabilities catalog, a reminder that the access layer in front of internal apps is itself a target. The gateway you choose is part of that attack surface.

What an auth gateway actually does

A reverse-proxy auth gateway sits in front of one or more applications and intercepts requests. Before traffic reaches the app, the gateway confirms the user is authenticated, and in the stronger designs that they are still authorized for this specific request. There are two common integration patterns. In forward-auth, an existing reverse proxy (nginx, Traefik, Caddy) asks the gateway “is this request allowed?” on a subrequest. In the full-proxy model, the gateway is the proxy and terminates the connection itself.

The distinction that matters most for security is authentication versus authorization. Authenticating means confirming who the user is, once, at login. Authorizing means deciding whether that identity may perform this action, ideally checked on every request. Tools that only authenticate leave a gap: once a session exists, the gateway stops asking questions. Tools that authorize per request can revoke access mid-session when identity, device state, or context changes. That difference drives most of the comparison below.

oauth2-proxy: the minimal forward-auth layer

oauth2-proxy is the simplest of the four. As its own documentation puts it, it “intercepts requests to your application and redirects users to an OAuth2 provider for authentication,” supporting Google, Microsoft Entra ID, GitHub, login.gov, and any generic OIDC provider. It is a small, single-purpose binary that pairs naturally with an existing nginx or Traefik setup through forward-auth.

Its strength is also its limit. oauth2-proxy delegates all authentication to an external identity provider and does not act as an IdP itself. It provides, in its own words, “a simple and secure way to protect your web applications with OAuth2 / OIDC authentication,” the operative word being authentication. Its documented weakness for a security-conscious deployment is the absence of a native per-request authorization model or native MFA. Once a user has a valid session, oauth2-proxy is not the layer enforcing fine-grained, continuously evaluated policy; you rely on the upstream IdP and the app for that. For a single low-risk internal app fronted by a corporate IdP that already enforces MFA, this is often enough. For anything needing policy at the gateway, it is thin.

Authelia: the self-hosted MFA portal

Authelia is a self-hosted authentication and authorization server with a login portal. Unlike oauth2-proxy, it can be its own identity source: its GitHub project describes it as OpenID Certified across Basic, Implicit, Hybrid, Form Post, and Config OpenID Provider profiles, meaning it can act as an OIDC provider rather than only delegating to one. It supports first-factor username/password plus a genuine range of second factors — FIDO2 WebAuthn security keys such as a YubiKey, TOTP authenticator apps, Duo mobile push, and passwordless passkeys.

On authorization, Authelia’s docs are explicit: it “can apply authorization policies to individual website resources which restrict which identities can access which resources from a given remote address,” and policies can “require 1FA, 2FA, or outright deny access.” That makes it far more than a login redirect — it is a per-resource policy engine with a built-in MFA portal, all self-hosted.

Its weakness is operational. Authelia is a stateful service you run and secure yourself: session storage, a database, notifier configuration, and the login portal all become your responsibility, and its own documentation does not describe continuous device-posture evaluation the way the identity-aware proxies do. For a homelab or a single team it is excellent; at scale you are on the hook for its high availability and hardening, and it becomes a component your CAB must track like any other change-controlled system. Our guide to securing self-hosted BI tools with change control and SSO walks through exactly that operational burden.

Pomerium: per-request, identity-aware proxy

Pomerium is an identity-aware reverse proxy built on Envoy, following the BeyondCorp and zero-trust model. It delegates authentication to your existing identity provider (“Users sign in through your identity provider”), but its differentiator is enforcement. Pomerium’s documentation states plainly that “Every request is authenticated and authorized” and that it works by “continually verifying a user’s identity, device state, and request context before granting access.” The flow is a two-step: authenticate against the IdP, then authorize against policy on every request.

That per-request, context-aware model is the strongest authorization posture of the four self-hostable options. It means a session does not become a free pass; if policy or context changes, the next request is re-evaluated.

Pomerium’s weakness is that it is not an identity provider and adds real architectural weight. It still requires an external IdP for authentication, so you are running Pomerium plus an IdP, not one system. Being built on Envoy, it is more moving parts than a single Go binary, and its docs do not specify a simple story for what happens to policy language and evaluation as sessions age. For teams that already run an IdP and want defensible per-request control, that complexity buys real security; for a two-app deployment it can be overkill.

Cloudflare Access: the managed ZTNA option

Cloudflare Access is the only fully managed option here. It is a zero-trust network access service that replaces VPNs with identity-first access to self-hosted apps, SaaS, and infrastructure. Policies can validate users against an IdP and check selectors including login methods, identity-provider groups, SAML groups, OIDC claims, and Cloudflare account membership. Notably, its docs confirm continuous evaluation: “Non-identity attributes are polled continuously, meaning they are evaluated with each new HTTP request for changes during the user session.” It also supports IdP-free machine access through Service Auth using service tokens and mutual TLS.

The appeal is that you do not operate it. There is no session store to secure, no portal to patch, no Envoy fleet to run.

Its weakness is the cloud dependency and the trust boundary that comes with it. Access is a Cloudflare-operated service, so your internal-app authorization now depends on a third-party control plane and on routing traffic through Cloudflare’s edge. That is a deliberate trade: you exchange operational burden for vendor concentration and a dependency your incident response and vendor-risk review must account for. For a change board, adopting it means adding Cloudflare to your critical-vendor list, not removing a component from your own stack. Our DORA operational-resilience checklist covers how to document exactly that kind of third-party dependency.

Capability matrix

The matrix below compiles the documented capabilities of all four, using each project’s own docs. A check mark means the capability is native and documented; a tilde means partial or dependent on an external IdP; a dash means not native.

Capability matrix comparing oauth2-proxy, Authelia, Cloudflare Access, and Pomerium across own-IdP, external-IdP delegation, native MFA, per-request authorization, continuous evaluation, self-hosting, and managed SaaS.

The pattern is clear. oauth2-proxy is the lightest and the least opinionated about authorization. Authelia is the most self-contained for teams that want their own MFA portal. Pomerium and Cloudflare Access both deliver per-request, context-aware authorization, with Pomerium self-hosted and Cloudflare managed. None of the four is an all-round winner; each trades something. For the broader set of change and access tooling, see our tools comparisons pillar.

What to do about it

  1. Map the app’s risk before the tool. A read-only internal dashboard and a production admin panel do not need the same gateway. Match the authorization strength to the blast radius.
  2. Decide self-hosted versus managed first. If you cannot accept a third-party control plane in front of internal apps, Cloudflare Access is out and the choice is among the three self-hostable options.
  3. If you only need login, use oauth2-proxy. Pair it with your existing IdP and reverse proxy. Do not add Pomerium’s complexity for a problem oauth2-proxy solves.
  4. If you need an MFA portal you control, choose Authelia, and budget for running it as a stateful, change-controlled service with real high-availability requirements.
  5. If you need continuous per-request authorization, choose Pomerium (self-hosted) or Cloudflare Access (managed). Both re-evaluate context per request; pick based on who operates it.
  6. Put the gateway in your change process. Whichever you choose, treat it as a change-controlled component: version its config, review its access policies on a schedule, and price a check against the live CISA KEV feed into your patch cadence, since the access layer is itself a target.

FAQ

Is oauth2-proxy enough on its own for internal apps?

For a single low-risk app behind a corporate IdP that already enforces MFA, often yes. oauth2-proxy authenticates the user and hands off; it does not enforce native MFA or per-request authorization itself, so higher-risk apps usually need Authelia, Pomerium, or Cloudflare Access.

Can Authelia replace my identity provider?

Partly. Authelia is OpenID Certified as an OpenID Provider, so it can act as an OIDC identity source and issue tokens, and it runs its own MFA portal. Whether it replaces an existing enterprise IdP depends on your directory and provisioning needs; many teams run it alongside one.

What is the difference between Pomerium and Cloudflare Access?

Both enforce per-request, context-aware authorization. Pomerium is self-hosted and built on Envoy, so you run it and it delegates authentication to your IdP. Cloudflare Access is a managed service that runs on Cloudflare’s edge, removing operational burden but adding a cloud dependency.

Do any of these provide multi-factor authentication natively?

Authelia does, with FIDO2 WebAuthn, TOTP, Duo push, and passkeys. Cloudflare Access enforces MFA through the connected IdP and one-time PIN flows. oauth2-proxy and Pomerium rely on the upstream identity provider for MFA rather than providing it themselves.

Which is easiest to operate?

Cloudflare Access, because it is fully managed, with no session store, portal, or proxy fleet to run. Among self-hosted options, oauth2-proxy is the simplest single binary, while Authelia and Pomerium are more capable but carry more operational and change-management overhead.

How does an auth gateway affect SOC 2 or DORA evidence?

It becomes an access-control point auditors will sample. Its authentication logs, authorization policies, and access reviews are evidence. A per-request authorization model produces stronger, more continuous evidence than a login-only gateway, which matters for both SOC 2 access controls and DORA’s operational-resilience expectations.

Sources

#auth gateway #reverse proxy #SSO #zero trust #oauth2-proxy #Authelia #Pomerium #Cloudflare Access

Published September 23, 2026.