Reverse Proxy: How It Works & Example Architecture

Accessing modern infrastructure requires more than a network-level foothold. As services spread across clouds, clusters, and regions, the question of who can reach what stops being a network question and becomes an identity question. Reverse proxies are the component that answers it.

A reverse proxy sits between clients and backend services, validating identity and enforcing authorization on every inbound request before any application is touched. This post explains what a reverse proxy is, how a reverse proxy works end-to-end, how it compares to a VPN (Virtual Private Network), and walks through an identity-aware reverse proxy architecture built with Envoy and Keycloak.

What is a reverse proxy?

A reverse proxy is a server-side intermediary that receives inbound requests on behalf of one or more backend services. In a reverse proxy model, clients talk to the proxy, and the proxy talks to the applications. This ensures that from the outside, there is a single, uniform entry point, regardless of how many services sit behind it.

It helps to contrast this with a forward proxy, which sits on the client side and routes outbound traffic on behalf of a user or device. A forward proxy controls what users can reach on the internet. A reverse proxy controls what the internet (or any client) can reach inside your infrastructure. The distinction matters for security design: reverse proxies let operators enforce policy at the point of entry, rather than relying on each backend service to do it correctly and consistently.

Modern reverse proxies, including Envoy, NGINX, Traefik, HAProxy, and other managed identity-aware proxies, do far more than load balancing. They terminate TLS (Transport Layer Security) connections, validate identity tokens, enforce per-route authorization, rewrite paths, and emit structured access logs. In a zero-trust architecture, the reverse proxy is the policy enforcement point for every request.

How a reverse proxy works

Every request that reaches a reverse proxy goes through the same lifecycle, though the specific checks vary by configuration.

First, the proxy terminates the inbound connection. TLS is decrypted at the edge so the proxy can inspect the request. HTTP/2 or HTTP/3 multiplexing is handled here, and the proxy has full visibility into headers, paths, and methods.

Second, the proxy authenticates the identity. In an identity-aware deployment, authentication typically means validating a JWT signed by an identity provider, verifying an mTLS client certificate, or checking a session cookie against a session store. Identity is verified once, at the edge, so applications can trust what the proxy tells them.

Third, the proxy evaluates authorization per route. Each path, and each HTTP method on that path, can carry its own access rule. A request might be allowed for one user and denied for another, even when the underlying route, cluster, and backend are identical. Authorization is evaluated request-by-request rather than session-by-session.

Fourth, the proxy forwards the request to the appropriate backend, often attaching verified identity claims as headers so the backend doesn't have to re-parse the token. Applications can act on identity without re-implementing authentication.

Finally, the proxy logs the outcome: who made the request, what they tried to reach, whether they were allowed, and why. Because every request passes through this layer, the access log becomes a canonical audit trail, independent of any individual application's logging.

The key property of a reverse proxy is that authentication and authorization live in a single, centrally managed layer, rather than being scattered across every service. A reverse proxy ensures that policy changes are made in one place and take effect for every route behind the proxy.

Reverse proxy vs. VPN

While reverse proxies and VPNs both control access to internal systems, they operate on fundamentally different trust models. This difference shows up in everything from lateral movement risk to audit quality.

A VPN establishes trust at the network layer. Once a user authenticates and joins the VPN, their device is placed on a network segment and, from that point on, can reach anything reachable from that segment. The access decision happens once at connection time, and it is coarse-grained (e.g., only broadly specifying that "this device can talk to this subnet"). Applications behind the VPN typically have no cryptographic evidence of the user's identity. Instead, they see an internal IP address and infer trust from the network topology.

A reverse proxy evaluates trust at the request layer. There is no network segment to join. Instead, every HTTP request carries its own identity (usually a bearer token), and every request is authorized independently against the policy for that specific route and method. This ensures that even a compromised token has a limited blast radius, and can not be used to escalate permissions beyond the original grants or to traverse laterally in the network.

Reverse proxies have the following advantages over VPNs:

• Authorization granularity: While VPN access is typically subnet-wide, reverse-proxy authorization scopes access per-route, per-method, per-user, and per-request.
• Lateral movement: On a VPN, a compromised endpoint has a wide attack surface: anything the subnet can reach. Behind a reverse proxy, the attacker's reach is capped at whatever paths the compromised identity is explicitly allowed to call.
• Audit fidelity: VPN logs capture connections: who logged in, when, from where. Reverse-proxy logs capture individual requests, identities, paths, and authorization decisions, which provides the granularity auditors and incident responders actually need.
• Zero-trust alignment: VPNs were designed for smaller, more homogeneous networks where implicit trust inside the perimeter was acceptable. Reverse proxies align with zero-trust principles: no implicit trust, identity verified on every request, and least privilege enforced at the policy layer.

None of these advantages make a VPN the wrong choice for every use case (they still have a role in specific scenarios), but for exposing application-layer services to identified users, a reverse proxy produces a materially stronger security posture.

When a reverse proxy architecture matters most

A reverse proxy is valuable anywhere policy needs to be consistent and auditable, but it becomes essential in a few specific environments.

In distributed and multi-cloud deployments, perimeter-based access using a VPN is no longer the silver bullet it once was, because there is no single "internal network" to put users on. A reverse proxy provides a single, consistent enforcement point regardless of where backends run, which cloud they run on, or how they're networked together.

In compliance-driven environments, the access log quality matters as much as the policy itself. A reverse proxy emits a structured, centralized record of every access decision, including denials, which is exactly the evidence auditors and incident responders need. That record exists independently of the applications themselves, so it survives even if a backend is compromised or misconfigured.

In teams managing many services with distinct authorization requirements, centralizing policy with a reverse proxy model avoids the drift and duplication that inevitably appear when each service implements its own auth. This is because reverse proxies provide a single place to update, to audit, and to extend if necessary.

Example architecture: An identity-aware reverse proxy with Envoy and Keycloak

As an example of how this works, here is a minimal reverse proxy architecture that demonstrates identity-aware, per-route authorization.

This example architecture contains three layers, as illustrated above:

• Keycloak, an open-source IAM tool, acts as the identity provider (IdP), authenticating users (alice and bob) and issuing RS256-signed JWTs (JSON Web Tokens). Keycloak exposes a JWKS (JSON Web Key Set) endpoint so that the proxy can verify token signatures without contacting the IdP on every request.
• Envoy, an open-source proxy for cloud-native applications, is the reverse proxy. Envoy terminates inbound requests on port 8080, validates JWTs against Keycloak's public keys, evaluates per-route RBAC (role-based access control) policy, and finally routes to the correct backend.
• Three sample applications (public-app, alice-app, and bob-app) sit behind Envoy on /public, /alice, and /bob. While these applications do nothing interesting themselves, they illustrate what the proxy decides to let through.

At the routing layer, Envoy maps each path prefix to a backend cluster:

route_config:
  virtual_hosts:
    - name: backend
      domains: ["*"]
      routes:
        - match: { prefix: "/public" }
          route: { cluster: public_app_cluster, prefix_rewrite: "/" }
        - match: { prefix: "/alice" }
          route:  { cluster: alice_app_cluster,  prefix_rewrite: "/" }
        - match: { prefix: "/bob" }
          route:  { cluster: bob_app_cluster,    prefix_rewrite: "/" }

Before any request hits those routes, the JWT authentication filter validates identity:

- name: envoy.filters.http.jwt_authn
  typed_config:
    providers:
      keycloak:
        issuer: "http://localhost:8180/realms/demo"
        remote_jwks:
          http_uri: { uri: "http://keycloak:8180/realms/demo/protocol/openid-connect/certs", cluster: keycloak_cluster }
        forward_payload_header: "x-jwt-payload"
        from_headers:
          - name: "Authorization"
            value_prefix: "Bearer "
    rules:
      - match: { prefix: "/health" }
      - match: { prefix: "/" }
        requires: { provider_name: "keycloak" }

This authentication alone isn't enough, because a valid token from Keycloak could belong to any user. The RBAC filter is what enforces who can reach what:

"allow-alice-only":
  permissions:
    - header: { name: ":path", string_match: { prefix: "/alice" } }
  principals:
    - metadata:
        filter: "envoy.filters.http.jwt_authn"
        path:
          - { key: "jwt_payload" }
          - { key: "preferred_username" }
        value: { string_match: { exact: "alice" } }

The payoff lands when Bob, a valid authenticated user, attempts to reach /alice with his own token. Envoy validates his JWT successfully (authentication passes), then evaluates the RBAC policy and denies the request with 403 Forbidden (authorization fails). Nothing reaches alice-app, and every step of that decision is written to the Envoy access log with Bob's identity attached.

This is the core property of an identity-aware reverse proxy: authentication and authorization are separate concerns, are enforced at the infrastructure layer, and are applied to each request independently. This also means that adding a new service behind the proxy becomes a routing-and-policy change rather than an auth-rewrite across multiple codebases.

Explore the GitHub repo at peteroneilljr/kubecon-ams-demo-v2 for more detail (this setup was used as a live demo at KubeCon Amsterdam).

Conclusion: The utility of reverse proxies

Reverse proxies move access control from the network perimeter and from scattered application code into a single, identity-aware layer. This allows them to:

• Enforce least privilege per request
• Scope blast radius to what an identity is explicitly allowed to reach
• Produce audit logs with the granularity that compliance and incident response actually require

Compared to a VPN, they replace a coarse, network-level trust decision with a fine-grained, request-level one, which is what zero-trust principles demand in cloud-native environments.

The Envoy and Keycloak example above is deliberately small, but the shape generalizes. Whether the proxy is Envoy, NGINX, a managed identity-aware proxy, or a service mesh ingress gateway, the architectural pattern is the same: verify identity once at the edge, evaluate authorization per route, forward with verified claims, and log every decision. That is the foundation most modern identity and access architectures are built on.

Read the documentation to learn how Teleport’s own reverse proxy architecture works.

About the author: Peter ONeill is a Solutions Engineering Manager at Teleport, specializing in identity-aware access control and zero-trust security architectures for enterprise customers with expertise spanning PKI infrastructure, reverse proxies, OAuth2/OIDC, and Kubernetes security patterns.

Related articles

→ What is a VPN (Virtual Private Network)?
→ Comparing TCP/IP and OSI Model
→ 3 VNet Use Cases to Simplify Internal Access
→ Teleport VNet Demo: Access Private TCP Apps Without VPNs