What Is an Identity-Aware Proxy?
An Identity-Aware Proxy (IAP) is a reverse proxy that authenticates and authorizes every request before forwarding it to a backend application. Unlike a traditional VPN that grants network-level access after a single authentication event, an IAP evaluates each HTTP request against an access policy that considers the user’s identity, group membership, device posture, geographic location, and request context. The backend application is never directly exposed to the internet; all traffic flows through the proxy, which acts as both a gatekeeper and an audit point.
The concept was popularized by Google’s BeyondCorp initiative, which eliminated VPN access for Google’s 100,000+ employees by placing every internal application behind an identity-aware proxy. Since then, the pattern has been adopted by organizations of all sizes through commercial products like Cloudflare Access, Zscaler Private Access, Akamai Enterprise Application Access, and open-source alternatives like Pomerium, OAuth2 Proxy, and Teleport.
Architecture of an IAP Deployment
A production IAP deployment consists of several interconnected components that work together to enforce Zero Trust access controls at the application layer.
Core Components
- The proxy service: Terminates TLS, receives incoming requests, and makes authorization decisions. This can be deployed as a cloud-hosted service (Cloudflare Access, Google IAP), a self-hosted reverse proxy (Pomerium, Envoy with ext_authz), or an edge function integrated into a CDN.
- The identity provider (IdP): Handles user authentication via OIDC or SAML. The IAP redirects unauthenticated users to the IdP for login and receives back a signed token containing the user’s identity and group claims. Common IdPs include Okta, Azure AD, Google Workspace, and Keycloak for self-hosted deployments.
- The device trust engine: Evaluates the security posture of the connecting device. This typically involves checking whether the device has an active endpoint protection agent, current OS patches, disk encryption enabled, and a valid device certificate. Solutions like CrowdStrike, Kolide, and Google Endpoint Verification provide device posture data to the IAP.
- The policy engine: Evaluates access policies against the combined signal from identity, device, and context. Policies are expressed as rules such as: “Allow access to the staging environment if the user is a member of the engineering group AND the device has a valid certificate AND disk encryption is enabled AND the request originates from a non-embargoed country.”
- The connector or tunnel: Provides secure connectivity between the IAP and the backend application without exposing the application to the internet. Cloudflare uses cloudflared tunnels, Zscaler uses App Connectors, and self-hosted solutions typically use WireGuard or SSH tunnels. The backend application listens only on localhost or a private subnet, making it unreachable from the public internet.
Deploying Pomerium as a Self-Hosted IAP
For organizations that need full control over their IAP infrastructure, Pomerium is a mature open-source option. It integrates with any OIDC-compliant identity provider, supports device posture checks, and can proxy HTTP, TCP, and gRPC traffic.
A typical Pomerium deployment defines routes in a YAML configuration file. Each route specifies the public-facing URL, the internal backend address, and the access policy. For example, a route for an internal Grafana instance would map the external domain grafana.corp.example.com to the internal address http://grafana.internal:3000, with a policy requiring the user to be a member of the engineering or SRE group. Pomerium handles TLS termination, OIDC authentication, session management, and request forwarding transparently.
For non-HTTP applications such as SSH, databases, or RDP, Pomerium provides a TCP proxy mode. Users authenticate through their browser, and Pomerium establishes a tunneled connection to the backend service. The user’s local client (SSH, psql, or an RDP client) connects to a local port opened by the Pomerium CLI, which forwards traffic through the authenticated tunnel. This eliminates the need for VPN access to reach these services.
Policy Design Patterns
Effective IAP policies go beyond simple group membership checks. Production deployments typically layer multiple signal types to make nuanced access decisions.
- Role-based access: Users in the finance group can access the accounting application. Users in the engineering group can access CI/CD dashboards and staging environments. This is the baseline policy layer and should cover 80% of access decisions.
- Device posture gating: Access to production environments requires a managed device with disk encryption, current OS patches (within 7 days of release), and an active EDR agent. Personal devices can access documentation and non-sensitive tools but are blocked from production systems.
- Contextual risk signals: Access from a new device or an unusual geographic location triggers step-up authentication (hardware security key required). Access from a known device and location uses standard OIDC authentication. This reduces friction for low-risk scenarios while increasing assurance for high-risk ones.
- Time-based restrictions: Certain administrative interfaces are accessible only during business hours. Off-hours access requires an approved change ticket or an on-call escalation.
- Request-level policies: For HTTP applications, policies can inspect the request path, method, and headers. Read-only access (GET requests) might be broadly available, while write operations (POST, PUT, DELETE) require additional group membership or approval.
Handling Authentication Flows for Non-Browser Clients
Web applications work naturally with IAP because the authentication flow uses standard browser redirects. Non-browser clients such as CLI tools, APIs, CI/CD pipelines, and mobile applications require alternative authentication mechanisms.
For automated systems and CI/CD pipelines, the IAP should support service account authentication using JWT tokens or mutual TLS certificates. The pipeline authenticates directly to the IAP using a service account credential, receives a signed session token, and includes that token in subsequent requests. The IAP validates the token on each request without requiring a browser-based login flow.
For developer CLI tools, a device authorization flow works well. The tool opens a browser window for the developer to authenticate, receives an authorization code, exchanges it for an access token, and caches the token locally. Subsequent CLI invocations use the cached token until it expires. This pattern is used by tools like kubectl with OIDC plugins, the GitHub CLI, and cloud provider CLIs.
Operational Monitoring and Audit
One of the most significant advantages of an IAP over a VPN is the richness of the audit trail. Because the IAP processes every request, it can log the authenticated user identity, the target application and path, the device posture at the time of access, the policy decision (allow or deny with reason), and the response status code. This creates a comprehensive access audit trail that VPN logs cannot provide. VPN logs show that a user connected at a certain time and transferred a certain volume of data. IAP logs show that a specific user accessed a specific application path at a specific time from a specific device and the access was permitted because they met specific policy criteria.
Feed these logs into your SIEM and build detections for anomalous patterns: a user accessing an application they have never accessed before, a burst of denied requests from a single user (potential credential compromise), or access from a device that recently failed a posture check. These signals are high-fidelity because they are based on authenticated, contextualized data rather than raw network flows.
Identity-Aware Proxies are not a future concept. They are production-proven infrastructure that eliminates the need for VPN access to web applications and, increasingly, to non-web services as well. The investment in deploying and operating an IAP pays for itself in reduced attack surface, improved user experience, and audit capabilities that compliance teams will appreciate.