Identity-Aware Proxy (IAP) was supposed to make secure access simple. Instead, it often becomes a tangle of hidden constraints, undocumented behavior, and silent failures. You set it up. You think it works. Then a user can’t connect, an API breaks, or a deployment stalls because a service account token expired in the background.
One of the biggest pain points with Identity-Aware Proxy is onboarding. Adding a new team member means juggling role assignments, service permissions, OAuth settings, sometimes project-level IAM changes. Each step hides behind menus, CLI flags, and inconsistent logs. It’s never truly repeatable, so your “quick” setup grows into tribal knowledge.
Debugging is worse. Identity-Aware Proxy often fails without clear errors. A 403 block could mean expired credentials, misaligned resource paths, or a subtle policy mismatch. Centralized error reporting isn’t a given, and reproducing the issue outside production can be nearly impossible without copying sensitive configs. Logs tell only part of the story, leaving you guessing where the request died.
Performance overhead is another friction point. IAP adds authentication and policy checks to every request. This can introduce latency or break streaming responses. If your system depends on real-time communication or large file transfers, these strict request boundaries can choke throughput. Testing in a development environment won't always surface these issues until they hit production.