Ask HN: 当 AI 开发代理启动短生命周期的应用程序时，您如何处理身份验证？
2 分•作者: NBenkovich•3 天前
Hi HN，
我正在开发用于软件开发的 AI 智能体。这些智能体可以自动启动短生命周期的应用实例——例如，针对每个拉取请求、每个任务或每个实验——每个实例都有自己的临时 URL。
身份验证的处理方式如下：
* OAuth2 / OIDC
* 外部身份提供商
* 重定向 URL 必须预先注册且是静态的
这与短生命周期应用产生了严重冲突：
* URL 是动态且不可预测的
* 重定向 URL 无法实际预先注册
* 身份验证成为唯一一个在其他方面完全自动化的工作流程中非短暂的部分
我看到团队通常采用以下做法：
* 在预览环境中禁用真正的身份验证
* 将所有回调路由到单个稳定的环境
* 使用通配符重定向或代理设置，感觉像是黑客行为
对于 AI 开发智能体来说，这尤其尴尬，因为它们假设基础设施是可抛弃的且完全自动化的——不需要手动配置 IdP。
所以，我很感兴趣：
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.