All posts

Deploying OIDC in a Private Subnet with a Secure Proxy

Deploying OpenID Connect (OIDC) inside a VPC with private subnets changes the game. No open internet traffic. No leaking tokens. No surface for attackers to probe. But once you shut the door to the public internet, you also lock yourself out—unless you plan the proxy path right. A private subnet deployment of OIDC inside AWS, GCP, or Azure demands a clear flow. The Identity Provider lives beyond your subnet. The workloads live within it. A proxy bridges that gap without weakening isolation. The

Free White Paper

Database Proxy (ProxySQL, PgBouncer) + Just-in-Time Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Deploying OpenID Connect (OIDC) inside a VPC with private subnets changes the game. No open internet traffic. No leaking tokens. No surface for attackers to probe. But once you shut the door to the public internet, you also lock yourself out—unless you plan the proxy path right.

A private subnet deployment of OIDC inside AWS, GCP, or Azure demands a clear flow. The Identity Provider lives beyond your subnet. The workloads live within it. A proxy bridges that gap without weakening isolation. The challenge is in preserving the OIDC handshake: discovery, authorization, and token exchange—all while keeping every packet inside an approved, encrypted tunnel.

Start with a VPC layout that makes the private subnets true to their name. Route outbound connections through a secure proxy in a public subnet or a fully managed egress service. Terminate TLS where it belongs: either in the proxy layer or directly inside the consuming service if performance and isolation need to stay absolute.

OIDC discovery documents and JWKS endpoints must be reachable without opening inbound ports. That means outbound-only HTTPS from your proxy, with return traffic tightly scoped by firewall rules or security groups. No wildcard egress. No “allow all” for convenience.

Continue reading? Get the full guide.

Database Proxy (ProxySQL, PgBouncer) + Just-in-Time Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Use the proxy to handle DNS resolution for the IdP, caching responses when possible. Private subnets without DNS planning will break your deployment before the first token request. Keep session lifetimes in sync with IdP defaults—private network retries can magnify clock drift issues that public deployments ignore.

Containerized workloads inside Kubernetes or ECS complicate the picture, but the principle is the same: the Pod or Task uses the proxy as its single egress route to the IdP. Sidecar or node-level proxy, the goal is minimal blast radius and predictable audit trails. Encrypt everything. Log everything. Never let the proxy become the weakest link.

Automation matters. Infrastructure as Code ensures that the OIDC VPC private subnet configuration is reproducible, testable, and version-controlled. Every CIDR, route table entry, and proxy setting deserves to be explicit. Compliance audits are faster when the deployment is code, not tribal knowledge.

When done right, OIDC inside a locked-down VPC proves you can run secure authentication flows without punching holes in your perimeter. It’s high focus, low noise engineering.

If you want to skip the days of trial and error and see a live OIDC private subnet proxy deployment in minutes, hoop.dev makes it possible. Build it. See it run. Tight, clean, and secure.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts