问HN：当AI开发代理启动短暂应用时，你们是如何处理身份验证的？
嗨，HN，
我正在研究用于软件开发的 AI 代理。这些代理会自动启动短暂的应用实例——例如，每个拉取请求、每个任务或每个实验——每个实例都有其自己的临时 URL。
身份验证采用标准方式处理：
- OAuth2 / OIDC
- 外部身份提供者
- 重定向 URL 必须提前注册并且是静态的
这与短暂应用的特性产生了严重冲突：
- URL 是动态且不可预测的
- 重定向 URL 实际上无法提前注册
- 身份验证成为了一个完全自动化工作流中唯一非短暂的部分
我看到团队通常采取的替代方案包括：
- 在预览环境中禁用真实身份验证
- 将所有回调路由通过一个稳定的环境
- 使用通配符重定向或代理设置，这些方法感觉像是变通方案
对于 AI 开发代理来说，这尤其尴尬，因为它们假设基础设施是可丢弃的并且完全自动化——没有手动的身份提供者配置参与其中。
所以我很好奇：
1. 如果你使用短暂的预览应用，你是如何处理真实身份验证的？
2. 是否有适用于动态 URL 的清晰 OAuth/OIDC 模式？
3. 静态重定向 URL 的假设在这里仍然是正确的模型吗？
4. 在生产环境中，什么方法实际上有效？
我在寻找真实的设置和失败故事，而不是理论。
查看原文
Hi HN,<p>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.<p>Auth is handled in the standard way:<p>- OAuth2 / OIDC<p>- external identity provider<p>- redirect URLs must be registered in advance and be static<p>This clashes badly with short-lived apps:<p>- URLs are dynamic and unpredictable<p>- redirect URLs can’t realistically be pre-registered<p>- auth becomes the only non-ephemeral part of an otherwise fully automated workflow<p>What I see teams doing instead:<p>- disabling real auth in preview environments<p>- routing all callbacks through a single stable environment<p>- using wildcard redirects or proxy setups that feel like hacks<p>This gets especially awkward for AI dev agents, because they assume infrastructure is disposable and fully automated – no manual IdP config in the loop.<p>So I’m curious:<p>1. If you use short-lived preview apps, how do you handle real auth?<p>2. Are there clean OAuth/OIDC patterns that work with dynamic URLs?<p>3. Is the static redirect URL assumption still the right model here?<p>4. What actually works in production?<p>Looking for real setups and failure stories, not theory.