OmniRoute 授权指南三路路由分类、策略管道与 fail-closed 设计解析【免费下载链接】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/OmniRouteOmniRoute 对每一个进入网关的 HTTP 请求都执行一条“感知路由”的授权管道authz pipeline请求先被确定性地分类为PUBLIC/CLIENT_API/MANAGEMENT三类之一再交由对应的策略policy评估放行或拒绝任何无法分类的路由一律降级为MANAGEMENT强制要求管理会话或管理级凭据即 fail-closed。读完本篇你可以掌握 OmniRoute 两种认证方式API Key Bearer 与 Dashboard 会话 Cookie、三种路由类的判定规则、src/server/authz/管道八个处理阶段的源码细节、公开路由 allowlist 的“按形状拆分”安全约定以及新增路由、Scope 管理与调试排错的完整实操路径。图源 Mermaid 定义docs/diagrams/authz-pipeline.mmd。文档对应版本 v3.8.40Source of truthsrc/server/authz/、src/shared/constants/publicApiRoutes.ts、src/lib/api/requireManagementAuth.ts、src/shared/utils/apiAuth.ts。两种认证方式1. API KeyBearer用于 OpenAI/Anthropic/Gemini 兼容的客户端 API以及当密钥带managescope 时部分 management 路由Authorization: Bearer api-key密钥由src/sse/services/auth.ts中的isValidApiKey()/extractApiKey()校验并经src/shared/utils/apiAuth.ts再导出。校验器同时接受环境变量OMNIROUTE_API_KEY/ROUTER_API_KEY作为持久化透传密钥issue #1350。从源码实现看CLIENT_API策略对凭据来源的提取并不只认Authorization头。clientApi 策略 中的extractBearer()按优先级依次尝试Authorization: Bearer token且仅当它确实是Bearer 非空 token形式时才短路——非 Bearer 形式的 Authorization 头不会阻断后续判断避免误杀 VS Code Copilot 这类自带 token 的客户端x-api-key头Gemini 系客户端gemini-cli / google/genai专用的x-goog-api-key头issue #7034最后兜底走extractApiKey(request)含 URL 透传路径。另外还有一个特殊豁免/api/v1/ws的 WebSocket 描述符握手GET/HEAD/OPTIONS 且 query 带handshake1属于元数据读取策略直接以anonymous放行真正的鉴权在路由处理器内完成。2. Dashboard 会话auth_token Cookie用于 Dashboard 页面与运维管理操作Cookie: auth_tokenJWT signed with JWT_SECRET由src/shared/utils/apiAuth.ts的isDashboardSessionAuthenticated()校验。管道会在 30 天寿命的 JWT 剩余不足 7 天时自动续期——pipeline.ts 中refreshDashboardSessionIfNeeded()计算exp - now小于7 * 24 * 60 * 60秒即签发自带authenticated: true声明、有效期 30 天的新 JWT并按x-forwarded-proto自适应设置Secure属性。两个值得注意的源码级细节authenticated: true是会话的必要条件。verifyDashboardSessionToken()src/shared/utils/dashboardSessionToken.ts验证 JWT 时要求该 claim 存在。用JWT_SECRET签发的其他 JWT例如 Cursor CLI 透传为密钥持有者铸造的iss omniroute / aud cursor-clitoken不是会话#13298管道在自动续期时发现 Cookie 里躺着无法识别为 Dashboard 会话的 JWT会主动删除该 Cookie防止外来 token“搭车”。过期/篡改的 JWT 会被静默丢弃。isStaleDashboardJwtError()识别ERR_JWS_SIGNATURE_VERIFICATION_FAILED、ERR_JWT_EXPIRED等错误码删除 Cookie 并仅打一次告警日志不向客户端泄露细节。部分 management 路由接受两种模式中的任意一种Cookie 会话或带manage或adminscope 的Bearer key。这正是 v3.8 引入的“通过 API 调用进行配置”configurable via API calls工作流的基础。此外Dashboard 管理登录还支持一个可选的 OIDCOpenID Connect流程作为默认密码登录的补充密码登录永不移除仅当settings.oidcEnabled true且oidcIssuer/oidcClientId/oidcClientSecret全部配置Settings → Auth时启用否则GET /api/auth/oidc/login返回400/api/auth/oidc/login从 Issuer 的/.well-known/openid-configuration发现authorization_endpoint回退到issuer/authorize基于入站请求感知x-forwarded-proto构造回调地址并用存入httpOnlyoidc_stateCookie 的随机state防 CSRF 后重定向到 IdP/api/auth/oidc/callback校验state、交换授权码并通过 Issuer 的 JWKSjose的createRemoteJWKSet按 JWKS URI 缓存验证 ID token 签名及issuer/audience。可选的oidcAllowedSubjects白名单匹配 token 的sub声明或其email声明——email仅在email_verified true时才被采信未验证邮箱永远无法通过门禁成功后铸造与密码登录完全相同的 30 天auth_tokenJWTsrc/app/api/auth/login/route.ts因此自动续期、Cookie 标志等会话管道完全不变——OIDC 只改变 Cookie 的铸造方式不改变其权限。三个路由类src/server/authz/types.ts定义了三个路由类任何无法被确定性分类的路由回落到MANAGEMENT路由类说明所需认证PUBLIC明确安全的路由——登录、登出、状态、init、健康检查、引导式 onboarding无CLIENT_API模型服务端点——/api/v1/*、/api/v1beta/*以及别名/v1/*、/v1beta/*、/chat/completions、/responses、/models、/codex/*当生效的REQUIRE_API_KEY特性开关开启时要求 Bearer 密钥MANAGEMENTDashboard 页面、设置、供应商、密钥、管理端与诊断端点Dashboard 会话或带managescope 的 Bearer分类结果不是一个裸枚举而是带“原因”的结构。从 types.ts 可以看到RouteClassification同时携带routeClass、reason13 种ClassificationReason如client_api_v1、client_api_alias、public_prefix、fallback_management等与归一化后的normalizedPath。原因字段用于遥测、诊断与测试保证每个路由决策都是可复核的——你可以在响应头或日志里回答“这条路径为什么被判为 MANAGEMENT”。classify.ts 展示了判定的完整顺序别名归一化normalizePathname()控制段做大小写不敏感匹配Next 的 rewrite 层接受/V1/...、/CODEX等大写写法分类器必须识别同样的大小写否则大写别名会落入 management 回退分支导致分类结果与实际分发的路由类不一致——GHSA-jvqc-mp9f-q936。规则包括/codex→/api/v1/responsesclient_api_codex_alias/v1/v1/...双前缀折叠client_api_double_prefix/v1、/v1beta→ 对应/api/v1*client_api_alias/chat/completions、/responses、/models→/api/v1/*规范路径。根路径/→MANAGEMENTroot_redirect随后由管道 301 到/dashboard。/dashboard/onboarding→PUBLICsetup_wizard/connect、/connect/*工单门禁的设备流连接页→PUBLICpublic_connect_page。/dashboard/*→MANAGEMENTdashboard_prefix。/api/v1/*、/api/v1beta/*→CLIENT_API永远如此——不会落入后面的 PUBLIC fall-through。其余/api/*命中公开 allowlist →PUBLIC未命中 →MANAGEMENTmanagement_api。兜底任何不属于以上的前缀 →MANAGEMENTfallback_management即 fail-closed 的最终保障。管道八个处理阶段所有请求经src/proxy.ts进入runAuthzPipeline()pipeline.tsIncoming request → src/proxy.ts → runAuthzPipeline() in src/server/authz/pipeline.ts 1. Strip trusted internal headers (x-omniroute-auth-*, x-omniroute-route-class) 2. Generate request id, classify route via classifyRoute() 3. If pathname / → redirect /dashboard 4. If draining (graceful shutdown) and /api/* → 503 5. If non-GET /api/* → checkBodySize() guard 6. If OPTIONS → CORS preflight 204 7. If options.enforce false → pass-through with route-class headers 8. Otherwise: POLICIES[routeClass].evaluate(ctx) - allow → stamp x-omniroute-auth-{kind,id,label,scopes} → NextResponse.next() - reject → JSON error w/ correlation_id (dashboard pages → 302 /login)结合源码几个关键阶段的真实行为值得展开阶段 1防伪造的头部剥离。受信任的内部头集中定义在 headers.tsx-request-id、x-omniroute-route-class、x-omniroute-auth-{kind,id,label,scopes}、x-omniroute-peer-locality、x-omniroute-trusted-peer-ip即AUTHZ_TRUSTED_HEADERS列表。管道在分类之前把它们从入站请求中全部删除客户端无法预先填充这些头来冒充特权主体。此外x-omniroute-peer-ip/x-omniroute-via-proxy这两个 peer 定位戳只允许来自自定义 Node 服务器在 Next 运行前盖戳、HMAC 与OMNIROUTE_PEER_STAMP_TOKEN校验且在被转发前同样剥离——路由处理器永远不能依据可伪造的Host头判断 locality。阶段 4/5优雅停机与体积守卫。/api/*在 draining 状态下一律 503带Retry-After: 5非 GET/非 OPTIONS 的/api/*请求先过checkBodySize()体积上限可从设置缓存getCachedSettings()动态获取。阶段 8 之前的 IP 过滤。checkRequestIP()对非 loopback 请求执行操作者配置的黑/白名单#6131loopback 被豁免保证本地运维者永远能进 Dashboard 修复名单。拒绝分支的差异化处理。策略拒绝时若路径属于 Dashboard 页面/dashboard、/home及其子路径管道返回302 重定向到/login并删除auth_tokenCookieAPI 端点则返回 JSON 错误体{ error: { code, message, correlation_id } }correlation_id与响应头x-request-id一致便于排障关联。管理写请求的 Origin/CSRF 二次校验。MANAGEMENT 路由 dashboard_session 非安全方法非 GET/HEAD/OPTIONS的组合会额外走validateBrowserMutationOrigin()同源写入必须带合法 CSRF tokenvalidateDashboardCsrfToken否则返回 403INVALID_ORIGIN。通过后的 subject 盖章。策略放行后stampSubject()把x-omniroute-auth-{kind,id,label,scopes}写入转发给处理器的请求头下游处理器通过assertAuth()读取无需重跑鉴权逻辑。策略注册表极其简单是三个类到策略的映射pipeline.tsconst POLICIES: RecordRouteClass, RoutePolicy { PUBLIC: publicPolicy, CLIENT_API: clientApiPolicy, MANAGEMENT: managementPolicy, };策略契约每个路由类在src/server/authz/policies/下都有一个策略publicPolicypolicies/public.ts——恒返回allow({ kind: anonymous, id: anonymous })。clientApiPolicypolicies/clientApi.ts——提取 Bearer经validateApiKey()校验。判定顺序见 clientApi.ts无凭据WS 握手豁免 → 放行匿名Dashboard 会话 → 放行dashboard_session生效的REQUIRE_API_KEY关闭 → 匿名放行id: local否则 401AUTH_002。有凭据validateApiKey失败时——若REQUIRE_API_KEYfalse降级为匿名而不是拒绝issue #2257CLI 陈旧配置里残留的失效 key 不应把整个请求 401会记录告警以便观测否则 401AUTH_002Invalid API key。成功 →allow({ kind: client_api_key, id: key_最后4位 })maskKeyId()保证日志与 subject 里不出现完整密钥。生效的REQUIRE_API_KEY由isRequireApiKeyEnabled()解析优先级为DB feature flag override process.env.REQUIRE_API_KEY default因此 Dashboard Feature Flags 与环境变量一致地治理/api/v1/*、/api/v1beta/*及全部别名解析器故障时 fail-closed要求密钥。managementPolicypolicies/management.ts——这是最复杂的策略。从 management.ts 的evaluate()可以看到其判定瀑布顺序敏感内部 WS 桥接豁免/api/internal/codex-responses-ws携带 per-process 密钥x-omniroute-ws-bridge-secret且 SHA-256 哈希timingSafeEqual匹配时以management_keyws-bridge放行Tier 1 LOCAL_ONLY 门isLocalOnlyPath()命中且请求来自非 loopback也非私网 LAN时若路径在LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES当前为/api/mcp/内则带manage/adminscope 的有效 Bearer key/api/mcp/还接受窄化的mcp:connectscope#7895或已认证的 Dashboard 会话可以绕过其余情况 403LOCAL_ONLY。注意 bypass 的密钥提取使用{ allowUrl: false }——URL 携带的 token 永远不能满足 manage-scope bypass#3300 后续内部服务豁免/api/tools/traffic-inspector/internal/ingestloopback 自带 token 的 MITM 代理上报、内部 model-sync 请求正则匹配/api/providers/[name]/(sync-models|models)、Video Bridge broker/drilldownloopback 请求内 token 校验、loopback 内部服务请求、loopback CLI tokenhasValidLoopbackCliTokenMCP 路径 carve-out#9159/api/mcp/*对任意来源loopback/LAN/远端接受mcp:connect、manage或adminscope——因为 loopback/LAN 请求会跳过 Tier 1 门若不单独处理requireLogintrue时mcp:connect-only 密钥会被泛化的 API-key 分支拒绝isAuthRequired()短路非 ALWAYS_PROTECTED 路径且isAuthRequired()为 false 时匿名放行label: auth-disabledDashboard 会话→allow({ kind: dashboard_session, id: dashboard })Scoped CLI access tokenremote 模式oma_前缀 token 在 API-key 分支之前评估evaluateAccessTokenAuth()因为它本质是管理凭据而非推理 API 密钥insufficientscope 返回 403AUTH_SCOPEmanage-scope API keyextractApiKey(request, { allowUrl: false })提取仍然 header-onlyisValidApiKeyhasManageScope(scopes)通过则放行DB/存储故障返回503AUTH_BACKEND_UNAVAILABLE而非 403——把“认证后端不可用”误报成“凭据错误”会误导调用方兜底拒绝有 Bearer 头 → 403AUTH_001Invalid management token无 Bearer → 401AUTH_001Authentication required。成功策略返回的AuthSubject中kind ∈ { client_api_key, dashboard_session, management_key, anonymous }。下游处理器应通过 assertAuth.ts 的assertAuth(request, CLIENT_API)读取而不是重跑鉴权逻辑。assertAuth()本身是防御纵深请求头里缺少x-omniroute-route-class时抛出AuthzAssertionErrorcodeAUTHZ_NOT_INITIALIZED500——中间件被绕过时测试立刻可见路由类与期望不符抛AUTHZ_ROUTE_CLASS_MISMATCH非 PUBLIC 却拿到 anonymous subject 抛AUTHZ_UNAUTHENTICATED401。公开路由 Allowlist按“形状”拆分src/shared/constants/publicApiRoutes.ts是显式 allowlist。这个文件按形状拆分成多个集合而且这种拆分是“承重的”load-bearing——GHSA-74g9-q8f6-793h 的教训前缀用startsWith()匹配因此也会匹配所有共享开头字符的相邻路径。当年/api/usage/om-usage作为前缀使/api/usage/om-usage任意后缀都被标为 PUBLIC而 Next 把它解析到动态路由/api/usage/[connectionId]——一个自身没有任何鉴权、完全依赖被分类为 MANAGEMENT 的处理器。从当前源码publicApiRoutes.ts可以看到修正后的四个集合// 真正的子树。每个条目必须以 / 结尾由单元测试断言。 PUBLIC_API_ROUTE_PREFIXES [ /api/auth/oidc/, /api/v1/, // 在 classify 中按 CLIENT_API 处理而非“无鉴权公开” /api/oauth/, /api/codex/connect/, // 工单门禁的 Codex 设备流完成处理器自带一次性 ticket 校验 /api/telegram/, // Telegram webhook处理器自带 initData HMAC 校验 /api/cursor-cli/, // Cursor CLI 透传处理器自带 API key / 会话 JWT 校验 ]; // 单条路由按 EXACT 路径匹配含不带尾斜杠的写法。 PUBLIC_API_ROUTES_EXACT new Set([ /api/auth/login, /api/auth/logout, /api/auth/status, /api/init, /api/sync/bundle, /api/cli/connect, // remote 模式 bootstrap密码换 scoped CLI token /api/usage/om-usage, // EXACT兄弟路由 /api/usage/[connectionId] 自身无鉴权 /api/skills/collect/chaos, // 处理器自带 Bearer chaosModeEnabled 校验 ]); // 只读单路由同时享受 CORS origin 放宽。 PUBLIC_READONLY_CORS_API_ROUTES [ /api/health/ping, /api/monitoring/health, /api/settings/require-login, ]; // 只读单路由无 CORS 放宽探针没有 key401 与错误密钥不可区分故必须无 key 可达。 PUBLIC_READONLY_API_ROUTES_EXACT new Set([/api/health]); PUBLIC_READONLY_METHODS new Set([GET, HEAD, OPTIONS]);还有两个易被忽略的配套细节PUBLIC_CLOUD_API_ROUTES/api/cloud/authPOST、/api/cloud/model/resolvePOST、/api/cloud/models/aliasGET/HEAD按“路径 方法”精确匹配isPublicApiRoute()先于 exact/prefix 分支检查它们LOCAL_ONLY_OAUTH_IMPORT_ROUTES/api/oauth/cursor/auto-import与/api/oauth/kiro/auto-import被显式排除在 PUBLIC 前缀之外isPublicApiRoute()开头即返回 false因为它们读取宿主本地凭据文件必须落入 MANAGEMENT 从而命中 LOCAL_ONLY 循环回环门GHSA-wgwc-crjm-pmwv / GHSA-gxv4-955v-v6cm。只读路由仅对安全方法GET/HEAD/OPTIONS公开且分类器中的只读 CORS 放宽判定matchesReadonlyPublic()使用 exact 匹配而非startsWith避免把 CORS origin 放宽泄漏给所有相邻路径。最后强调classifyRoute()把/api/v1/*与/api/v1beta/*排除在 PUBLIC fall-through 之外——它们永远是CLIENT_APIBearer 密钥策略仍然生效。新增路由的三个模式模式 1 — 客户端 API 端点Bearer 认证/api/v1/与/api/v1beta/下的路由自动被分类为CLIENT_API。管道强制 Bearer 检查处理器不必重复该检查但可以在需要时读取 subject// src/app/api/v1/your-route/route.ts import { NextRequest, NextResponse } from next/server; import { assertAuth } from /server/authz/assertAuth; export async function POST(req: NextRequest) { const subject assertAuth(req, CLIENT_API); // subject.kind client_api_key | anonymous | dashboard_session // ... handler logic }模式 2 — 管理端点会话或 Bearer manage使用src/lib/api/requireManagementAuth.ts的requireManagementAuth()import { requireManagementAuth } from /lib/api/requireManagementAuth; export async function POST(request: Request) { const rejection await requireManagementAuth(request); if (rejection) return rejection; // ... handler logic }requireManagementAuth()成功时返回null否则返回 JSON 错误Response401AUTH_001Authentication required—— 完全没有凭据403—— Bearer 无效或Bearer 存在但密钥缺少manage/adminscope。hasManageScope(scopes)对manage或admin返回 true。从 requireManagementAuth.ts 的实现看它的检查顺序与中央managementPolicy保持同源no driftisAuthRequired()短路可用alwaysRequireAuth: true覆盖→ Dashboard 会话 → loopback 内部服务 → 本地 CLI token含管道盖章的local-cli-tokensubject→oma_scoped access token → header-only API key 分支allowUrl: false。可选参数acceptMcpConnectScope仅 MCP 传输路由stream/sse/status/tools可启用让窄化mcp:connectscope 也能通过其余管理路由保持 manage-only。后端故障isValidApiKey抛异常统一映射为 503 而非 403。模式 3 — 加入公开 allowlist按形状选择集合而不是图省事单条路由放进PUBLIC_API_ROUTES_EXACTGET-only 则进PUBLIC_READONLY_CORS_API_ROUTES只有真正的子树才能进PUBLIC_API_ROUTE_PREFIXES且必须以/结尾。把单条路由放进前缀列表会连带公开所有共享其开头字符的相邻路径——包括日后在动态段旁边新增的兄弟路由GHSA-74g9-q8f6-793h 即此模式。同步更新单元测试tests/unit/public-api-routes.test.ts、tests/unit/authz/public-route-exact-match.test.ts与tests/unit/authz/classify.test.ts——前者的public-route-exact-match.test.ts专门断言前缀条目必须以/结尾。Scope 体系API 密钥携带scopes数组以 JSON 存于api_keys.scopes见src/lib/db/apiKeys.ts。管理 scopemanage/admin—— 允许密钥以 Bearer 方式访问 management API 端点。规范定义位于src/shared/constants/managementScopes.tshasManageScope在此requireManagementAuth.ts只是向后兼容的再导出。MCP scopesrc/shared/constants/mcpScopes.ts每个 MCP 工具通过MCP_TOOL_SCOPES要求特定 scope。完整列表MCP_SCOPE_LISTread:health, read:combos, write:combos, read:quota, read:usage, read:models, execute:completions, execute:search, write:budget, write:resilience, pricing:write, read:cache, write:cache, read:compression, write:compression, read:proxiesopen-sse/mcp-server/server.ts中的 scope 执行流程resolveCallerScopeContext()先从 MCP 认证信息、请求元数据或OMNIROUTE_MCP_SCOPES环境变量解析出调用者 scope 集合随后每个工具调用把自己的 scope 列表交给evaluateToolScopes()判定。认证必需开关src/shared/utils/apiAuth.ts的isAuthRequired()决定请求是否要强制任何认证settings.requireLogin false→ 全局禁用认证未配置密码且无INITIAL_PASSWORD环境变量 → bootstrap 模式放行 onboarding 向导与 loopback 请求但暴露到网络上的请求仍需要凭据任何 DB 错误 → fail-closedsecure-by-default。注意ALWAYS_PROTECTED 路由isAlwaysProtectedPath()不受requireLoginfalse豁免——managementPolicy在 Tier 2 短路之前先检查它。客户端 API 的密钥强制不使用process.env.REQUIRE_API_KEY直读而是src/shared/utils/featureFlags.ts的isRequireApiKeyEnabled()。对已部署实例意义重大在 Dashboard → Feature Flags 中切换REQUIRE_API_KEY会把 override 写入 DB 并立即作用于/v1/*、/v1beta/*、/models、/responses、/chat/completions、/codex/*以及其他共享该 helper 的客户端 API 鉴权检查flag 存储不可读时客户端 API 认证 fail-closed 并强制要求密钥。破坏性变更与行为变更Breaking Change — v3.8.0/api/v1/agents/tasks/*与/api/resilience/model-cooldowns现在要求 management 认证commit588a0333。此前发送普通无managescopeAPI key 的客户端会收到403。迁移方式在 API Keys dashboard 给密钥授予managescope或改用已登录的 Dashboard 会话。Behaviour Change — v3.8.2/api/mcp/*远端 MCP 服务器默认仍是 LOCAL_ONLY但现在接受带managescope 的Authorization: Bearer api-key的非 loopback 请求。该豁免按路径显式门禁位于src/server/authz/routeGuard.ts的LOCAL_ONLY_MANAGE_SCOPE_BYPASS_PREFIXES兄弟 LOCAL_ONLY 前缀/api/cli-tools/runtime/*故意不在豁免列表内——它能派生任意子进程。来自非 loopback 的匿名请求访问/api/mcp/*仍然返回403 LOCAL_ONLY——任何新 LOCAL_ONLY 路径的默认值都是 strict-loopback。后续源码中/api/mcp/的豁免还扩展到窄化的mcp:connectscope见 #7895/#9159。详见 Route Guard Tiers。测试单元测试tests/unit/authz/——classify.test.ts、pipeline.test.ts、client-api-policy.test.ts、management-policy.test.ts、public-policy.test.ts公开 allowlisttests/unit/public-api-routes.test.ts聚焦运行node --import tsx/esm --test tests/unit/authz/classify.test.ts。调试管道总是在响应上盖章x-request-id: correlation id, echoed in error bodies x-omniroute-route-class: PUBLIC | CLIENT_API | MANAGEMENT对已认证的请求转发给处理器的上游请求头还包含x-omniroute-auth-kind: client_api_key | dashboard_session | management_key | anonymous x-omniroute-auth-id: key_last-4 | dashboard | anonymous x-omniroute-auth-label: (可选) x-omniroute-auth-scopes: 逗号分隔列表在处理器内使用assertAuth(req, expectedClass)—— 若中间件被绕过它会抛出带AUTHZ_NOT_INITIALIZED码的AuthzAssertionError对测试中捕获配置回退非常有用。延伸阅读API_REFERENCE.md —— 每个端点的 auth 标记COMPLIANCE.md —— auth 事件的审计日志MCP-SERVER.md —— MCP scope 执行细节ROUTE_GUARD_TIERS.md —— LOCAL_ONLY / ALWAYS_PROTECTED 分级源码入口src/server/authz/、src/lib/api/requireManagementAuth.ts【免费下载链接】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），仅供参考