OmniRoute Kiro 多账号配置指南利用 AWS SSO OIDC 客户端隔离解决会话冲突【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本指南以 OmniRoute免费 MIT 协议 AI 网关接入 AWS 托管的 AI 编程助手 Kiro 为主题重点解决在同一台机器、同一个 OmniRoute 实例上同时运行多个 Kiro 账号而互相顶号的经典问题。读完本文你将掌握 Kiro 会话冲突的根因、OmniRoute v3.8.0 的 OIDC 客户端隔离机制、五种账号导入方式的使用场景以及基于 API Key 的无 OAuth 会话认证方案并能独立完成双账号并排配置与故障排查。背景为什么 Kiro 账号会互相冲突Kiro 的后端使用AWS SSO OIDC 客户端注册client registration来追踪活动会话其关键约束是每个 OIDC 客户端注册在同一时刻只支持一个活动会话。当第二个设备或用户使用同一个已注册客户端完成认证时后端会直接吊销第一个账号的 refresh token。这也是在已经登录了某个 Kiro 账号的机器上再次执行kiro-cli login时出现问题的根本原因——新登录会撤销旧账号的 token导致旧账号被强制下线。换言之冲突并非 Kiro 账号本身的限制而是共享同一个 OIDC 客户端注册导致的会话抢占。从源码看这一注册动作对应 OmniRoute 的KiroService.registerClient()实现src/lib/oauth/services/kiro.ts它向https://oidc.region.amazonaws.com/client/register发送 POST 请求携带clientName、clientType、scopes、grantTypes、issuerUrl等配置定义于 src/lib/oauth/constants/oauth.ts并返回clientId、clientSecret与clientSecretExpiresAt三个字段。这正是后续隔离方案的核心数据结构。OmniRoute 如何解决v3.8.0自v3.8.0起OmniRoute 在每次 Kiro 连接导入时都会调用registerClient()AWS SSO OIDC为每一条 OmniRoute 连接分配一个独立的 OIDC 客户端注册。由于不同客户端注册彼此独立刷新或重新认证某一个账号不会影响任何其他账号的 refresh token。隔离能力覆盖所有基于 refresh token 的导入方式而 API Key 认证则完全不经过 OIDC 刷新会话。各导入方式的隔离状态如下表导入方式隔离状态AWS Builder ID / IDC device-code flow自 device-code flow 引入起即完全隔离Import Token手动粘贴 refresh token自 v3.8.0 起隔离Google / GitHub 社交登录自 v3.8.0 起隔离Auto-Import读取 kiro-cli SQLite自 v3.8.0 起隔离SQLite 路径原本已隔离SSO-cache fallback 现在同样隔离API Key长期 CodeWhisperer 密钥无刷新会话密钥经 AWS 校验后作为 bearer 凭据存储源码侧的隔离实现在 KiroService.validateImportToken() 中可以看到完整的隔离调用链首先校验 token 前缀必须以aorAAAAAG开头否则抛出 Invalid token format尝试用~/.aws/sso/cache中缓存的客户端凭据Builder ID 路径直接刷新失败后走 Kiro 社交认证刷新端点关键步骤无论上述刷新走哪条路径都会调用registerClient(region)为该连接注册一个全新且独立的 OIDC 客户端并把clientId、clientSecret、clientSecretExpiresAt一并写入返回结果——这正是每个连接拥有专属客户端注册的落地之处源码注释中明确标记对应 issue #2328。相应地POST /api/oauth/kiro/import路由src/app/api/oauth/kiro/import/route.ts会把上述字段持久化进providerSpecificData并在刷新失败时通过sanitizeErrorMessage()返回可读的错误信息而非笼统的 500。v3.8.0 之前创建的连接迁移说明在 v3.8.0 之前导入的连接其providerSpecificData中没有独立的 OIDC 客户端注册。它们仍然可以工作但走的是共享的社交认证刷新端点因此两条这样的旧连接依然可能互相吊销。要获得隔离请执行迁移在Dashboard → Providers中删除旧连接然后使用任意受支持的导入方式重新导入。所有新建连接会自动获得专属的客户端注册。并排添加两个 Kiro 账号前置条件OmniRoutev3.8.0 或更高版本。一个可用的 Kiro 账号邮箱 密码、Google 或 GitHub 登录均可。可选第二个 Kiro 账号。第 1 步导入第一个账号打开Dashboard → Providers → Add Provider → Kiro。选择以下任一方式Import Token—— 粘贴以aorAAAAAG开头的 refresh token。API Key—— 粘贴长期有效的 Kiro / CodeWhisperer API 密钥。Google / GitHub login—— 在浏览器中完成 OAuth 流程。Auto-Import—— 点击按钮OmniRoute 自动从本地 kiro-cli 数据库或~/.aws/sso/cache读取凭据。连接保存完成。基于 refresh token 的流程会自动注册专属 OIDC 客户端API Key 流程则会在 AWS 侧校验密钥且不存储 refresh token。第 2 步导入第二个账号对第二个账号重复第 1 步。由于每次导入都会创建独立的 OIDC 客户端注册两条连接完全隔离互不影响。第 3 步验证两条连接均处于活动状态Dashboard → Providers—— 两条 Kiro 连接都应显示Active状态。Dashboard → Health—— 两条连接都应通过各自的 token 健康检查。第 4 步用 combo 在两个账号之间路由创建一条以两个连接为目标端的 combo即可在两者之间做负载均衡或故障切换kiro/kiro-dev → kiro/kiro-procombo 的完整配置方法可参考 FEATURES.md 及路由相关文档。Enterprise / IDC 用户对于 AWS IAM Identity CenterIDC账号请使用Dashboard → Providers → Kiro → Device Code下的AWS Builder ID / IDC device-code流程。device-code 流程自引入起就完全隔离无需重新导入已有连接。在非默认 AWS 区域运行的企业用户可以通过 Import Token API 指定区域curl -X POST http://localhost:20128/api/oauth/kiro/import \ -H Content-Type: application/json \ -d {refreshToken: aorAAAAAG..., region: eu-west-1}region字段省略时默认us-east-1。在路由实现中import/route.ts若请求体同时携带clientId与clientSecretauto-import 从 SSO cache 注册文件提取的 IDC 凭据则直接走区域化 OIDC 端点刷新并标记authMethod: idc、provider: Enterprise不再重复调用registerClient()而社交 / Builder ID token 则统一经validateImportToken()内部注册独立客户端。此外该路由还支持targetProvideramazon-q查询参数将连接落为 Amazon Q 而非 Kiro。API Key 导入流程API Key 认证面向 Kiro / AWS CodeWhisperer 的长期 bearer 凭据。它不依赖 OAuth 刷新因此天然规避了共享 OIDC 会话被吊销的问题。通过 Dashboard打开Dashboard → Providers → Kiro。选择API Key。粘贴 API 密钥并可选填写 AWS 区域默认us-east-1。OmniRoute 校验密钥后保存连接。通过 APIcurl -X POST http://localhost:20128/api/oauth/kiro/api-key \ -H Content-Type: application/json \ -d {apiKey: kiro_or_codewhisperer_key, region: us-east-1}内部契约POST /api/oauth/kiro/api-key路由src/app/api/oauth/kiro/api-key/route.ts调用KiroService.validateApiKey()校验密钥后者通过 listAvailableProfiles() 调用ListAvailableProfiles请求发往按区域匹配的 CodeWhisperer / Amazon Q 端点——us-east-1使用https://codewhisperer.us-east-1.amazonaws.com其他区域使用https://q.region.amazonaws.com并解析出profileArn。值得注意的是部分长期 API Key 能调用生成接口却被ListAvailableProfiles明确拒绝AccessDeniedException源码将这类 profile 解析失败视为可选发现失败而非硬性认证失败kiro.ts不会阻塞导入。保存后的连接结构为{ authType: apikey, providerSpecificData: { authMethod: api_key, region: us-east-1, profileArn: arn:aws:codewhisperer:... } }另外由于密钥没有定时刷新机制路由会写入一个一年后的expiresAt时间戳避免健康检查 / token 路径将连接误判为立即过期api-key/route.ts。运行时KiroExecutor.buildHeaders()open-sse/executors/kiro.ts根据providerSpecificData.authMethod判断是否 API Key是则取apiKey字段发送Authorization: Bearer key并附加tokentype: API_KEY头quota/profile 调用沿用同一标记AWS 因而将其视为长期 API 密钥而非 OIDC 或社交访问令牌。OIDC 客户端过期AWS SSO OIDC 公共客户端通常在90 天后过期clientSecretExpiresAt。OmniRoute 会在providerSpecificData中保存该时间戳用于可观测性。如果某条连接在约 90 天后停止刷新重新导入该连接即可获得全新的 OIDC 客户端注册。到期自动重新注册被列为未来的改进方向。API Key 连接不存在 OIDC 客户端过期问题因为它们不通过 AWS SSO OIDC 刷新。故障排查第二个账号仍然被登出在Dashboard → Providers检查两条连接通过信息图标查看原始 JSON确认每条连接的clientId非空。若任一连接缺少clientId说明它是 v3.8.0 之前导入的——请重新导入。导入报错 Token validation failed确认 refresh token 以aorAAAAAG开头源码中validateImportToken()对此有硬性前缀校验kiro.ts。确认 OmniRoute 能访问https://oidc.us-east-1.amazonaws.com或所配置的区域。若位于企业代理之后请在Dashboard → Settings → Proxies中为 provider 设置代理导入路由会通过resolveProxyForProvider()按 provider 级 → 全局 → 直连的顺序解析代理import/route.ts。API Key 导入失败确认粘贴的是 Kiro / CodeWhisperer API 密钥而非 refresh token。确认 AWS 区域与密钥 / 账号匹配默认us-east-1。密钥必须能够调用ListAvailableProfiles否则 OmniRoute 无法解析所需的profileArn。其他问题请参阅主排障文档 TROUBLESHOOTING.md。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 19:28:17 · 阅读 1.2k OmniRoute Kiro 多账号配置指南：利用 AWS SSO OIDC 客户端隔离解决会话冲突
OmniRoute Kiro 多账号配置指南利用 AWS SSO OIDC 客户端隔离解决会话冲突【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute本指南以 OmniRoute免费 MIT 协议 AI 网关接入 AWS 托管的 AI 编程助手 Kiro 为主题重点解决在同一台机器、同一个 OmniRoute 实例上同时运行多个 Kiro 账号而互相顶号的经典问题。读完本文你将掌握 Kiro 会话冲突的根因、OmniRoute v3.8.0 的 OIDC 客户端隔离机制、五种账号导入方式的使用场景以及基于 API Key 的无 OAuth 会话认证方案并能独立完成双账号并排配置与故障排查。背景为什么 Kiro 账号会互相冲突Kiro 的后端使用AWS SSO OIDC 客户端注册client registration来追踪活动会话其关键约束是每个 OIDC 客户端注册在同一时刻只支持一个活动会话。当第二个设备或用户使用同一个已注册客户端完成认证时后端会直接吊销第一个账号的 refresh token。这也是在已经登录了某个 Kiro 账号的机器上再次执行kiro-cli login时出现问题的根本原因——新登录会撤销旧账号的 token导致旧账号被强制下线。换言之冲突并非 Kiro 账号本身的限制而是共享同一个 OIDC 客户端注册导致的会话抢占。从源码看这一注册动作对应 OmniRoute 的KiroService.registerClient()实现src/lib/oauth/services/kiro.ts它向https://oidc.region.amazonaws.com/client/register发送 POST 请求携带clientName、clientType、scopes、grantTypes、issuerUrl等配置定义于 src/lib/oauth/constants/oauth.ts并返回clientId、clientSecret与clientSecretExpiresAt三个字段。这正是后续隔离方案的核心数据结构。OmniRoute 如何解决v3.8.0自v3.8.0起OmniRoute 在每次 Kiro 连接导入时都会调用registerClient()AWS SSO OIDC为每一条 OmniRoute 连接分配一个独立的 OIDC 客户端注册。由于不同客户端注册彼此独立刷新或重新认证某一个账号不会影响任何其他账号的 refresh token。隔离能力覆盖所有基于 refresh token 的导入方式而 API Key 认证则完全不经过 OIDC 刷新会话。各导入方式的隔离状态如下表导入方式隔离状态AWS Builder ID / IDC device-code flow自 device-code flow 引入起即完全隔离Import Token手动粘贴 refresh token自 v3.8.0 起隔离Google / GitHub 社交登录自 v3.8.0 起隔离Auto-Import读取 kiro-cli SQLite自 v3.8.0 起隔离SQLite 路径原本已隔离SSO-cache fallback 现在同样隔离API Key长期 CodeWhisperer 密钥无刷新会话密钥经 AWS 校验后作为 bearer 凭据存储源码侧的隔离实现在 KiroService.validateImportToken() 中可以看到完整的隔离调用链首先校验 token 前缀必须以aorAAAAAG开头否则抛出 Invalid token format尝试用~/.aws/sso/cache中缓存的客户端凭据Builder ID 路径直接刷新失败后走 Kiro 社交认证刷新端点关键步骤无论上述刷新走哪条路径都会调用registerClient(region)为该连接注册一个全新且独立的 OIDC 客户端并把clientId、clientSecret、clientSecretExpiresAt一并写入返回结果——这正是每个连接拥有专属客户端注册的落地之处源码注释中明确标记对应 issue #2328。相应地POST /api/oauth/kiro/import路由src/app/api/oauth/kiro/import/route.ts会把上述字段持久化进providerSpecificData并在刷新失败时通过sanitizeErrorMessage()返回可读的错误信息而非笼统的 500。v3.8.0 之前创建的连接迁移说明在 v3.8.0 之前导入的连接其providerSpecificData中没有独立的 OIDC 客户端注册。它们仍然可以工作但走的是共享的社交认证刷新端点因此两条这样的旧连接依然可能互相吊销。要获得隔离请执行迁移在Dashboard → Providers中删除旧连接然后使用任意受支持的导入方式重新导入。所有新建连接会自动获得专属的客户端注册。并排添加两个 Kiro 账号前置条件OmniRoutev3.8.0 或更高版本。一个可用的 Kiro 账号邮箱 密码、Google 或 GitHub 登录均可。可选第二个 Kiro 账号。第 1 步导入第一个账号打开Dashboard → Providers → Add Provider → Kiro。选择以下任一方式Import Token—— 粘贴以aorAAAAAG开头的 refresh token。API Key—— 粘贴长期有效的 Kiro / CodeWhisperer API 密钥。Google / GitHub login—— 在浏览器中完成 OAuth 流程。Auto-Import—— 点击按钮OmniRoute 自动从本地 kiro-cli 数据库或~/.aws/sso/cache读取凭据。连接保存完成。基于 refresh token 的流程会自动注册专属 OIDC 客户端API Key 流程则会在 AWS 侧校验密钥且不存储 refresh token。第 2 步导入第二个账号对第二个账号重复第 1 步。由于每次导入都会创建独立的 OIDC 客户端注册两条连接完全隔离互不影响。第 3 步验证两条连接均处于活动状态Dashboard → Providers—— 两条 Kiro 连接都应显示Active状态。Dashboard → Health—— 两条连接都应通过各自的 token 健康检查。第 4 步用 combo 在两个账号之间路由创建一条以两个连接为目标端的 combo即可在两者之间做负载均衡或故障切换kiro/kiro-dev → kiro/kiro-procombo 的完整配置方法可参考 FEATURES.md 及路由相关文档。Enterprise / IDC 用户对于 AWS IAM Identity CenterIDC账号请使用Dashboard → Providers → Kiro → Device Code下的AWS Builder ID / IDC device-code流程。device-code 流程自引入起就完全隔离无需重新导入已有连接。在非默认 AWS 区域运行的企业用户可以通过 Import Token API 指定区域curl -X POST http://localhost:20128/api/oauth/kiro/import \ -H Content-Type: application/json \ -d {refreshToken: aorAAAAAG..., region: eu-west-1}region字段省略时默认us-east-1。在路由实现中import/route.ts若请求体同时携带clientId与clientSecretauto-import 从 SSO cache 注册文件提取的 IDC 凭据则直接走区域化 OIDC 端点刷新并标记authMethod: idc、provider: Enterprise不再重复调用registerClient()而社交 / Builder ID token 则统一经validateImportToken()内部注册独立客户端。此外该路由还支持targetProvideramazon-q查询参数将连接落为 Amazon Q 而非 Kiro。API Key 导入流程API Key 认证面向 Kiro / AWS CodeWhisperer 的长期 bearer 凭据。它不依赖 OAuth 刷新因此天然规避了共享 OIDC 会话被吊销的问题。通过 Dashboard打开Dashboard → Providers → Kiro。选择API Key。粘贴 API 密钥并可选填写 AWS 区域默认us-east-1。OmniRoute 校验密钥后保存连接。通过 APIcurl -X POST http://localhost:20128/api/oauth/kiro/api-key \ -H Content-Type: application/json \ -d {apiKey: kiro_or_codewhisperer_key, region: us-east-1}内部契约POST /api/oauth/kiro/api-key路由src/app/api/oauth/kiro/api-key/route.ts调用KiroService.validateApiKey()校验密钥后者通过 listAvailableProfiles() 调用ListAvailableProfiles请求发往按区域匹配的 CodeWhisperer / Amazon Q 端点——us-east-1使用https://codewhisperer.us-east-1.amazonaws.com其他区域使用https://q.region.amazonaws.com并解析出profileArn。值得注意的是部分长期 API Key 能调用生成接口却被ListAvailableProfiles明确拒绝AccessDeniedException源码将这类 profile 解析失败视为可选发现失败而非硬性认证失败kiro.ts不会阻塞导入。保存后的连接结构为{ authType: apikey, providerSpecificData: { authMethod: api_key, region: us-east-1, profileArn: arn:aws:codewhisperer:... } }另外由于密钥没有定时刷新机制路由会写入一个一年后的expiresAt时间戳避免健康检查 / token 路径将连接误判为立即过期api-key/route.ts。运行时KiroExecutor.buildHeaders()open-sse/executors/kiro.ts根据providerSpecificData.authMethod判断是否 API Key是则取apiKey字段发送Authorization: Bearer key并附加tokentype: API_KEY头quota/profile 调用沿用同一标记AWS 因而将其视为长期 API 密钥而非 OIDC 或社交访问令牌。OIDC 客户端过期AWS SSO OIDC 公共客户端通常在90 天后过期clientSecretExpiresAt。OmniRoute 会在providerSpecificData中保存该时间戳用于可观测性。如果某条连接在约 90 天后停止刷新重新导入该连接即可获得全新的 OIDC 客户端注册。到期自动重新注册被列为未来的改进方向。API Key 连接不存在 OIDC 客户端过期问题因为它们不通过 AWS SSO OIDC 刷新。故障排查第二个账号仍然被登出在Dashboard → Providers检查两条连接通过信息图标查看原始 JSON确认每条连接的clientId非空。若任一连接缺少clientId说明它是 v3.8.0 之前导入的——请重新导入。导入报错 Token validation failed确认 refresh token 以aorAAAAAG开头源码中validateImportToken()对此有硬性前缀校验kiro.ts。确认 OmniRoute 能访问https://oidc.us-east-1.amazonaws.com或所配置的区域。若位于企业代理之后请在Dashboard → Settings → Proxies中为 provider 设置代理导入路由会通过resolveProxyForProvider()按 provider 级 → 全局 → 直连的顺序解析代理import/route.ts。API Key 导入失败确认粘贴的是 Kiro / CodeWhisperer API 密钥而非 refresh token。确认 AWS 区域与密钥 / 账号匹配默认us-east-1。密钥必须能够调用ListAvailableProfiles否则 OmniRoute 无法解析所需的profileArn。其他问题请参阅主排障文档 TROUBLESHOOTING.md。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考