Ask HN: How do you handle auth when AI dev agents spin up short-lived apps?
9 comments
For what it looks, this is something where DCR (https://openid.net/specs/openid-connect-registration-1_0.htm...) could be helpful.
Some auth providers like Auth0 have support for it: https://auth0.com/docs/get-started/applications/dynamic-clie....
There are some caveats and security concerns when using DCR, so you should research more into that. Another option may be CIMD (https://www.ietf.org/archive/id/draft-parecki-oauth-client-i...) though I'm not totally familiar with it.
What you also mentioned, like using proxys, or wildcards, is also widely used, at least for what I've seen.
Some auth providers like Auth0 have support for it: https://auth0.com/docs/get-started/applications/dynamic-clie....
There are some caveats and security concerns when using DCR, so you should research more into that. Another option may be CIMD (https://www.ietf.org/archive/id/draft-parecki-oauth-client-i...) though I'm not totally familiar with it.
What you also mentioned, like using proxys, or wildcards, is also widely used, at least for what I've seen.
We have a real setup that treats this challenge as a network isolation problem instead of an auth problem. Have you considered that approach?
Meaning: instead of trying to authenticate to the preview app, make the preview app only reachable via an encrypted application-layer channel. The "authentication" becomes having the encryption key to that channel.
For AI agents, this could simplify things:
Agent generates an encryption key when spinning up preview Preview app runs in isolated network (e.g., behind a customized Envoy proxy doing application-layer encryption without PKI/TLS) Agent communicates with preview over the secure channel No OAuth redirect URLs needed at all
The pattern we've been using is basically "encrypted lanes" between services - each preview gets its own lane(s), fully ephemeral. When the preview dies, the lane disappears.
Main downside is this doesn't help if you need humans to access the previews with their SSO credentials. But for agent-to-preview-app workflows, it's been cleaner than fighting OAuth's assumptions.
Curious if you've explored this direction or if there are constraints that make network isolation insufficient?
Meaning: instead of trying to authenticate to the preview app, make the preview app only reachable via an encrypted application-layer channel. The "authentication" becomes having the encryption key to that channel.
For AI agents, this could simplify things:
Agent generates an encryption key when spinning up preview Preview app runs in isolated network (e.g., behind a customized Envoy proxy doing application-layer encryption without PKI/TLS) Agent communicates with preview over the secure channel No OAuth redirect URLs needed at all
The pattern we've been using is basically "encrypted lanes" between services - each preview gets its own lane(s), fully ephemeral. When the preview dies, the lane disappears.
Main downside is this doesn't help if you need humans to access the previews with their SSO credentials. But for agent-to-preview-app workflows, it's been cleaner than fighting OAuth's assumptions.
Curious if you've explored this direction or if there are constraints that make network isolation insufficient?
This sounds like an interesting approach. I’m not fully sure I understand one thing though.
Are you suggesting to completely disable authentication inside the app and rely only on the encrypted channel? If yes, that’s not always an option — many apps have logic that depends on an authentication context, even in preview environments.
If not, how do you translate network-level authentication into app-level authentication? In other words, how does the app know who the caller is, beyond the fact that they can reach it over an encrypted lane?
The idea of treating this as a network isolation problem makes sense, but I’m trying to understand how it works when the app itself still expects a real auth context.
Are you suggesting to completely disable authentication inside the app and rely only on the encrypted channel? If yes, that’s not always an option — many apps have logic that depends on an authentication context, even in preview environments.
If not, how do you translate network-level authentication into app-level authentication? In other words, how does the app know who the caller is, beyond the fact that they can reach it over an encrypted lane?
The idea of treating this as a network isolation problem makes sense, but I’m trying to understand how it works when the app itself still expects a real auth context.
Good question. To clarify: the app still has its own internal auth
logic — we're not bypassing that.
The encrypted lane handles connection isolation (who can reach the app), while the app still handles identity (who the user is).
For agent-to-app communication specifically, the pattern we use: 1. Agent passes a short-lived token in the request payload (not URL) 2. App validates the token against its local auth store 3. The encrypted lane ensures no one else can intercept/replay that token
Let me clarify. I am not suggesting disabling authentication inside the app. I am suggesting a solution is to layer the network isolation + application auth. The secure application layer channel just removes the OAuth redirect dance for machine-to-machine flows.
For human access, you'd still need SSO. But once the human is authenticated, the services authenticate to one another (machine-to-machine) also at the application layer (not layers 3/4).
Does that make sense for your use case, or are you looking for something that works with human SSO flows too?
The encrypted lane handles connection isolation (who can reach the app), while the app still handles identity (who the user is).
For agent-to-app communication specifically, the pattern we use: 1. Agent passes a short-lived token in the request payload (not URL) 2. App validates the token against its local auth store 3. The encrypted lane ensures no one else can intercept/replay that token
Let me clarify. I am not suggesting disabling authentication inside the app. I am suggesting a solution is to layer the network isolation + application auth. The secure application layer channel just removes the OAuth redirect dance for machine-to-machine flows.
For human access, you'd still need SSO. But once the human is authenticated, the services authenticate to one another (machine-to-machine) also at the application layer (not layers 3/4).
Does that make sense for your use case, or are you looking for something that works with human SSO flows too?
We’ve ended up solving this with an OAuth mock.
The main advantages for us:
- The application code is exactly the same in prod and preview environments. The only thing that changes is the OAuth provider configuration (endpoints, secrets, etc.), not the auth flow itself.
- The mock lets you specify a user ID / username directly on the sign-in screen, without real credentials or email verification. That makes it usable both for humans testing previews and for agents or automated test suites.
- It also lets us simulate third-party identity providers (Google, etc.) without actually integrating with them in previews. Dealing with things like captchas or provider-side enforcement in ephemeral environments is another source of friction we wanted to avoid.
It’s not real auth, but it keeps previews fully functional and avoids special-casing large parts of the app just to make OAuth work with dynamic URLs.
The main advantages for us:
- The application code is exactly the same in prod and preview environments. The only thing that changes is the OAuth provider configuration (endpoints, secrets, etc.), not the auth flow itself.
- The mock lets you specify a user ID / username directly on the sign-in screen, without real credentials or email verification. That makes it usable both for humans testing previews and for agents or automated test suites.
- It also lets us simulate third-party identity providers (Google, etc.) without actually integrating with them in previews. Dealing with things like captchas or provider-side enforcement in ephemeral environments is another source of friction we wanted to avoid.
It’s not real auth, but it keeps previews fully functional and avoids special-casing large parts of the app just to make OAuth work with dynamic URLs.
There's actually loads of ways to solve this depending on what those apps are.
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.
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.
Wouldn't the client credentials app be a good fit for this? Or do you need user consent/scopes?
For redirect URLs, some identity providers let you configure them via an API key.
Which resources are protected by OAuth that you want these AI agents to interact with?
For redirect URLs, some identity providers let you configure them via an API key.
Which resources are protected by OAuth that you want these AI agents to interact with?
> Wouldn't the client credentials app be a good fit for this? Or do you need user consent/scopes?
If OAuth is already part of the product, switching flows only for preview environments isn’t really an option. It introduces a second auth path that doesn’t exist in production, which adds complexity and creates a risk of auth bugs that only appear later. In practice, teams want previews to exercise the same OAuth flow as prod, not a simplified one.
> For redirect URLs, some identity providers let you configure them via an API key.
That still means introducing provisioning and deprovisioning steps for every ephemeral environment. For example, platforms like Vercel give you PR-based preview URLs out of the box, but it’s not at all obvious how to automatically add and remove redirect URLs in the IdP for each of those. Auth becomes a special case that needs extra orchestration, while everything else is disposable.
> Which resources are protected by OAuth that you want these AI agents to interact with?
The issue isn’t agents accessing OAuth-protected resources directly. It’s agents building and testing applications that themselves rely on OAuth. The pain point is getting fully functional ephemeral environments when OAuth assumes static, pre-registered redirect URLs.
If OAuth is already part of the product, switching flows only for preview environments isn’t really an option. It introduces a second auth path that doesn’t exist in production, which adds complexity and creates a risk of auth bugs that only appear later. In practice, teams want previews to exercise the same OAuth flow as prod, not a simplified one.
> For redirect URLs, some identity providers let you configure them via an API key.
That still means introducing provisioning and deprovisioning steps for every ephemeral environment. For example, platforms like Vercel give you PR-based preview URLs out of the box, but it’s not at all obvious how to automatically add and remove redirect URLs in the IdP for each of those. Auth becomes a special case that needs extra orchestration, while everything else is disposable.
> Which resources are protected by OAuth that you want these AI agents to interact with?
The issue isn’t agents accessing OAuth-protected resources directly. It’s agents building and testing applications that themselves rely on OAuth. The pain point is getting fully functional ephemeral environments when OAuth assumes static, pre-registered redirect URLs.
> OAuth assumes static, pre-registered redirect URLs.
So sounds to me like you are talking about using the authorization code grant in your application and wanting different redirect URLs for each of these environments. Is my assumption correct?
If so, the options that I see are:
* register those URLs at environment creation time. You mention it isn't obvious how to do so. I'm sure that depends on each IDP. I can tell you how to do it for the company I work for (info in bio) but that won't help you if that is not the IDP you are using.
* use wildcarding for redirect URLs. While this is strongly discouraged in production environments, for dev and test environments I don't see a huge issue with it. Again this config is IDP dependent.
* don't use OAuth. The redirect you're frustrated with is a key part of OAuth. At least the authorization code grant. So if that's causing you headaches then don't use it. But I don't know another standards based way to authenticate that is as widely supported and as robust as OAuth/OIDC.
So sounds to me like you are talking about using the authorization code grant in your application and wanting different redirect URLs for each of these environments. Is my assumption correct?
If so, the options that I see are:
* register those URLs at environment creation time. You mention it isn't obvious how to do so. I'm sure that depends on each IDP. I can tell you how to do it for the company I work for (info in bio) but that won't help you if that is not the IDP you are using.
* use wildcarding for redirect URLs. While this is strongly discouraged in production environments, for dev and test environments I don't see a huge issue with it. Again this config is IDP dependent.
* don't use OAuth. The redirect you're frustrated with is a key part of OAuth. At least the authorization code grant. So if that's causing you headaches then don't use it. But I don't know another standards based way to authenticate that is as widely supported and as robust as OAuth/OIDC.
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.