I’m working on AI agents used for software development. These agents automatically spin up short-lived app instances – for example per pull request, per task, or per experiment – each with its own temporary URL.
Auth is handled in the standard way:
- OAuth2 / OIDC
- external identity provider
- redirect URLs must be registered in advance and be static
This clashes badly with short-lived apps:
- URLs are dynamic and unpredictable
- redirect URLs can’t realistically be pre-registered
- auth becomes the only non-ephemeral part of an otherwise fully automated workflow
What I see teams doing instead:
- disabling real auth in preview environments
- routing all callbacks through a single stable environment
- using wildcard redirects or proxy setups that feel like hacks
This gets especially awkward for AI dev agents, because they assume infrastructure is disposable and fully automated – no manual IdP config in the loop.
So I’m curious:
1. If you use short-lived preview apps, how do you handle real auth?
2. Are there clean OAuth/OIDC patterns that work with dynamic URLs?
3. Is the static redirect URL assumption still the right model here?
4. What actually works in production?
Looking for real setups and failure stories, not theory.
mattmanser•1h ago
You haven't given us enough detail of what you are actually trying to do for anyone to give you concrete advice.
But the answer is probably a reverse proxy, checking the auth on the way. It's a standard solution for things like this, just ask your favourite AI for an example of how you'd do it.
That's what your teams are effectively already doing (redirecting through a single stable environment), they've just not realised they've setup one of their servers as an ad-hoc reverse-proxy.
Your teams could do with some senior engineers who know what they're doing.