IT
InstaTunnel Team
Published by our engineering team
Beyond IP Whitelisting: Identity-Aware Developer Tunneling in 2026
Beyond IP Whitelisting: Identity-Aware Developer Tunneling in 2026
The “hole in the firewall” approach to developer tunneling is dead. For years, exposing a local port to the internet meant punching through your firewall, crossing your fingers, and hoping that an IP whitelist was enough. It wasn’t then, and in 2026 it absolutely isn’t now.
This post explores the full arc of that shift: from YAML-based identity policies in ngrok to the architectural guarantees of open-source Zero Trust platforms, and the very real, very exploitable danger lurking inside that ephemeral subdomain you registered to test your OAuth flow.
From Port Forwarding to Identity-Aware Edges
The fundamental question has changed. We no longer ask “Where is this request coming from?” — an IP address can be spoofed, VPNs can be compromised, and remote work shattered the idea of a trusted office network. The question now is “Who is making this request, and has their session been validated by our Identity Provider?”
That shift from network identity to human identity is what defines Zero Trust tunneling.
The ngrok Traffic Policy Engine
The most significant evolution in ngrok over the past two years is the move from simple command-line flags to a fully declarative, YAML-based Traffic Policy engine. This isn’t cosmetic. It fundamentally repositions ngrok from a convenience tool to something closer to an edge gateway.
Traffic Policy lets you intercept and act on requests in the ngrok cloud — before they ever reach localhost:3000. The engine uses Common Expression Language (CEL) expressions to filter traffic conditionally, and actions execute in a handler chain: each function either rejects a request or passes it down to the next handler.
The supported authentication phases are on_tcp_connect, on_http_request, and on_http_response. The auth methods you can enforce at the edge include Basic Auth, OAuth, OpenID Connect (OIDC), JWT validation, Mutual TLS (mTLS), and IP restrictions — all without touching your application code.
OAuth at the Tunnel Edge
To gate your local port behind a Google login, you define the policy in a YAML file and pass it to the ngrok agent:
oauth-policy.yml
on_http_request:
- actions:
- type: oauth config: provider: google allow_domains: ["yourcompany.com"] ngrok http 3000 --traffic-policy-file oauth-policy.yml When a user hits your tunnel URL, ngrok redirects them to Google, completes the OAuth flow, and only forwards the request to your machine if authentication succeeds. ngrok passes identity metadata downstream as headers — Ngrok-Auth-User-Email, Ngrok-Auth-User-Id, and Ngrok-Auth-User-Name — so your app can make authorization decisions without owning the auth flow.
OIDC for Enterprise IdPs
For teams using a corporate IdP like Okta, Azure AD, or any OIDC-compliant provider, the openid-connect action gives you the same edge enforcement with full enterprise identity semantics:
on_http_request:
- actions:
- type: openid-connect config: issuer_url: "https://your-org.okta.com" client_id: "" client_secret: "" scopes: - openid - profile - email
- actions:
- type: add-headers config: headers: x-identity-token: "${actions.ngrok.oidc.identity_token}" x-user-email: "${actions.ngrok.oidc.identity.email}" For the Okta setup, you register https://idp.ngrok.com/oauth2/callback as the Sign-in redirect URI in the Okta Admin Dashboard, then wire up the policy as above. The OIDC identity token gets forwarded to your upstream service via headers, enabling downstream authorization logic without your app needing to handle the OIDC flow itself.
Layering Rules
Traffic Policy rules execute in order, which means you can layer authentication with other actions. A practical production-grade configuration might enforce OIDC auth first, then apply rate limiting, then check IP reputation, all in the same YAML file. The handler chain model means invalid requests — unauthenticated, rate-limited, or from flagged IPs — are dropped at the edge and never touch your service.
Octelium: The Open-Source Contender for Unified Zero Trust
While ngrok operates as a SaaS platform, Octelium has emerged as the go-to for teams requiring a fully self-hosted, unified Zero Trust architecture. It is fully open source (Apache 2.0), and there is no proprietary cloud-based control plane — a meaningful distinction for organizations with data sovereignty requirements.
Octelium provides a scalable Zero Trust Architecture (ZTA) for identity-based, application-layer (L7) aware access via both private client-based access over WireGuard/QUIC tunnels, and public clientless BeyondCorp-style access. Access decisions are made on a per-request basis using context and policy, not simple network-level allow/block rules.
The Secretless Access Model
One of Octelium’s most distinctive capabilities is secretless access. An identity-aware proxy layer called Vigil intercepts requests, evaluates whether the user is authorized, and — if they are — injects application-layer credentials on the fly. HTTP API keys, database passwords, SSH private keys, and TLS certificates stay locked in Octelium’s secrets vault. The user never sees them, and they never leave the platform.
This eliminates an entire class of credential hygiene problems: no more distributing API keys to developers, no more SSH key sprawl, no more static tokens in CI/CD environment variables.
Policy-as-Code with CEL and OPA
Octelium’s access control uses ABAC (Attribute-Based Access Control) expressed through CEL and Open Policy Agent (OPA). This enables granular, context-aware rules that traditional network-layer tunnels simply cannot express:
Grant access only if the user is on a managed device within a specific geographic region.
Allow CI/CD runners to access your local MCP (Model Context Protocol) server using OIDC workload identity assertions rather than static API keys.
Enforce per-request access control rather than per-session — a compromised session doesn’t grant blanket access.
The network path itself is identity-driven: if a user is not authorized, the service path does not exist for them. There is no IP to scan, no port to probe. Contrast this with a traditional tunnel where the endpoint is “live” and waiting, visible to any scanner on the internet.
Architecture
Octelium is built on Kubernetes and supports both zero-config WireGuard/QUIC client tunnels and clientless browser-based access. It integrates with any OIDC or SAML 2.0 identity provider, and exposes an OpenTelemetry-native observability stack for real-time access auditing. The project also publishes a GitHub Action that lets CI/CD runners connect to an Octelium cluster directly from a workflow.
The OAuth Redirect Hijacking Trap
Here is a vulnerability that is still rampant in 2026, still poorly understood, and still causing real breaches. It lives in the gap between developer convenience and production security hygiene.
The Setup
You are testing a “Login with GitHub” integration locally. You spin up an ngrok free-tier tunnel and get an ephemeral subdomain — something like cool-app.ngrok-free.app. You register this URL as a valid OAuth redirect URI in your GitHub App settings, complete your testing, and kill the tunnel. Subdomain goes back into the free pool.
The Attack
An attacker running a subdomain-claiming script picks up cool-app.ngrok-free.app. Now, any user who clicks an old “Sign In” link — from a cached email, a staging Slack message, anywhere — will authenticate with GitHub and be redirected to your old subdomain with an authorization code in the URL: ?code=abc123.
The attacker’s server, now sitting on that subdomain, captures the code. They exchange it for an access token. They are now authenticated as your user.
This is not theoretical. Security research documented at Black Hat Asia demonstrated how URL parser inconsistencies in OAuth providers enabled attackers to hijack accounts across multiple real-world applications. Secureworks’ Counter Threat Unit has documented Azure redirect URI takeover as a concrete attack path where threat actors obtain access tokens while impersonating legitimate users. Research from early 2025 exposed a similar flaw integrated into dozens of airline booking systems, putting millions of users at risk.
The attack is compounded by wildcard redirect URI configurations. When an OAuth application permits any subdomain match (*.ngrok-free.app), an attacker doesn’t need to claim a specific old subdomain — any subdomain they control under that pattern works as a valid redirect target.
The Anatomy of a Silent Probe
The 2026 variant of this attack doesn’t wait for users to click old links. By crafting authorization URLs with prompt=none, attackers can silently check whether a user has an active session with an IdP and redirect them to a hijacked subdomain without ever displaying a login screen. The user sees nothing. The attacker gets a code.
Mitigations That Actually Work
Never use ephemeral subdomains for OAuth. Register a custom domain you own and control — dev.yourcompany.com — and use that as your redirect URI. When the tunnel dies, the domain doesn’t go anywhere.
Implement PKCE (Proof Key for Code Exchange). PKCE adds a code_verifier to the token exchange that is generated client-side and never transmitted over the wire. Even if an attacker intercepts the authorization code, they cannot exchange it for a token without the verifier. This is the single most effective mitigation against authorization code interception, and it should be mandatory on every OAuth flow you own.
Enforce exact redirect URI matching. Configure your IdP to require exact string matches — no wildcards, no prefix matching, no pattern-based rules. The OAuth specification recommends this, but many providers permit looser matching by default.
Validate the state parameter. The state parameter exists to prevent CSRF attacks in OAuth flows. Ensure it is generated with strong entropy, stored server-side before the redirect, and validated on return. Many implementations either omit it or check it inconsistently.
Keep tunnels short-lived. If you must use a SaaS tunnel for OAuth testing, set it to expire immediately after the session ends. Some teams script this as part of their test teardown.
Self-Hosting the Pipe: Bore, frp, and Pangolin
As data sovereignty requirements tighten and SaaS costs compound, a growing segment of the engineering community is moving to self-hosted tunneling. The reasoning is straightforward: a $5/month VPS and a Rust binary can provide more bandwidth, better privacy, and full control over your data — without monthly per-seat SaaS pricing.
The self-hosted ecosystem has matured considerably. Here is where the major tools stand.
Bore: Minimal, Fast, Memory-Safe
Bore is a Rust-based tunnel built for simplicity. Single binary, no complex configuration, minimal memory footprint. It is designed for the use case where a small team needs to expose local services for internal testing with zero latency overhead.
What Bore is not: an identity-aware proxy. It is explicitly a “dumb pipe” — fast, secure transport with no auth layer of its own. If you deploy Bore, you own the security at both ends. For temporary, internal-only testing between developers who trust each other, that tradeoff is acceptable. For anything touching external users or sensitive data, it is not.
Best for: Fast, temporary pipes for internal development workflows.
frp (Fast Reverse Proxy): The Swiss Army Knife
frp has been the reliable workhorse of the self-hosting world for years, and it remains the most feature-complete option for non-HTTP use cases. It supports TCP, UDP, HTTP, and HTTPS, which matters when you need to tunnel a database port, an RDP session, or a custom protocol alongside web traffic.
frp supports “Secret” modes that require clients to present a token before connecting, basic load balancing, and optional dashboard reporting. Configuration is verbose by modern standards — INI or YAML files with significant learning curve — but the breadth of supported protocols and the maturity of the project make it the default choice for complex self-hosted networking requirements.
Best for: Complex network topologies, non-HTTP protocols, teams already comfortable with configuration-heavy tooling.
Pangolin: The All-in-One Zero Trust Suite
Pangolin is the most significant new entrant in the self-hosted tunneling space. Built by Fossorial (a Y Combinator 2025 company), it has accumulated nearly 19,000 GitHub stars and 140,000+ installs in under a year. The pitch: Cloudflare Tunnels, but you own the infrastructure.
Pangolin combines a reverse proxy, VPN, and identity-aware access control into a single deployable stack. Under the hood it uses Traefik for routing and a custom WireGuard client called Newt that creates encrypted tunnels from remote networks to a central Pangolin server — no open ports required on the home or office router. It works cleanly through CGNAT, DS-Lite, and other restrictive ISP configurations.
The management layer is where Pangolin stands apart from Bore and frp. A web-based dashboard handles resource management, SSL certificate provisioning via Let’s Encrypt, user and role-based access control, and SSO/OIDC integration — all without touching config files. The Pangolin zero-trust model is implemented through a Traefik plugin called Badger, which authenticates every incoming request.
A major recent update pushed Pangolin further into ZTNA territory: native clients for Windows, macOS, and Linux now allow users to access resources across all connected sites using familiar LAN-style addresses, with DNS queries routed through the secure tunnel. This moves Pangolin from “self-hosted Cloudflare Tunnels” into genuine Twingate/Tailscale competitive territory.
The security story can be extended with CrowdSec integration, available via the installer script, which adds collective threat intelligence and real-time blocking to the Pangolin gateway.
Best for: Teams and homelab operators who want Cloudflare-level features — dashboard UI, SSO, RBAC, automatic SSL — with full infrastructure control and no vendor lock-in.
Comparison: Self-Hosted Tunnel Options
Feature Bore frp Pangolin
Language Rust Go Go / WireGuard
Security Model Pipe only Tokens / SSL OIDC / SAML / RBAC
Non-HTTP Support No Yes Yes (via clients)
Dashboard No Optional Yes (full management)
Setup Complexity Trivial Moderate Involved (Docker/VPS)
ZTNA Capabilities None None Yes
Best For Temporary pipes Complex networks Long-term Zero Trust
Putting It Together: A 2026 Developer Workflow
The practical synthesis of all of this looks something like the following.
For individual developers working on OAuth integrations or sharing local work with a client, ngrok’s Traffic Policy engine provides enterprise-grade identity enforcement with minimal ceremony. Define your OIDC or OAuth policy in YAML, start the tunnel with --traffic-policy-file, use a custom static domain rather than an ephemeral one, and implement PKCE in your OAuth flow. That is a secure, production-worthy local development setup.
For small to medium teams that need data sovereignty and are willing to operate a VPS, Pangolin is the current best-in-class option. The installer script handles the full stack — Pangolin, Gerbil, Traefik, Let’s Encrypt — and adding a new site is a single Docker container with three environment variables. The dashboard makes user and resource management accessible to non-engineers, and the OIDC integration means you can connect it to your existing identity provider.
For organizations with compliance requirements, multi-environment infrastructure, and engineering resources to operate Kubernetes, Octelium represents the most architecturally rigorous option. Secretless access, per-request policy evaluation, ABAC via CEL and OPA, OpenTelemetry-native observability, and a fully open-source, self-hosted control plane put it in a category of its own among open-source tools.
The Era of the Identity-Aware Edge
The tunnel is no longer a convenience hack. It is infrastructure — and it needs to be treated with the same rigor as your production environment.
The “punch a hole and hope for the best” era is over, closed out by a combination of maturing Zero Trust tooling, increasingly sophisticated OAuth hijacking attacks, and data sovereignty requirements that make SaaS-only approaches untenable for a growing number of organizations.
The tools to do this right — ngrok Traffic Policies, Octelium, Pangolin — are available today, many of them free and open source. The question is no longer whether you can afford to implement identity-aware tunneling. It is whether you can afford not to.
Related Topics
Top comments (0)