尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

J-Code 多 Provider 认证体系实战指南:OAuth 与 API-key 登录全解析

J-Code 多 Provider 认证体系实战指南:OAuth 与 API-key 登录全解析 J-Code 多 Provider 认证体系实战指南OAuth 与 API-key 登录全解析【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode本指南以 J-Code 仓库根目录的 OAUTH.md 为核心系统讲解 J-Code 内置的 OAuth 与 API-key 认证机制包括 ClaudeClaude Max、OpenAI/Codex、Azure OpenAI、Gemini、Google/Gmail 的原生 OAuth 登录流程以及 Fireworks、Novita AI、MiniMax、Cursor、Copilot、Antigravity 等实验性与 OpenAI 兼容 provider 的接入方式。读完本文你将掌握各 provider 的登录命令、凭证发现顺序、本地存储位置、认证排查手段以及源码级的行为原理如 Claude OAuth 合同、工具名称重映射、Responses API 路由。认证架构总览凭证发现与本地存储J-Code 的认证体系由两条路径构成检测本地已有凭证其他工具/CLI 遗留的登录态与内置 OAuth / API-key 登录流程jcode login --provider name。两条路径最终都收敛到统一的本地凭证存储供运行时 provider 使用。对于由其他工具/CLI 管理的认证文件如 Claude Code、OpenCode、pi、Codex CLI 的凭证jcode 在读取前会主动询问用户。一旦你批准某个来源jcode 会记住该外部认证文件路径的信任决定后续会话不再重复询问并且始终保留原文件不动——不做移动、重写或权限变更。对称链接symlink形式的外部认证文件会被直接拒绝。凭证统一存储在本地主要位置如下Provider / 来源存储位置J-Code Claude OAuthjcode login --provider claude~/.jcode/auth.jsonClaude Code CLI~/.claude/.credentials.jsonLinux/Windows或 macOS 登录 Keychain 项Claude Code-credentialsmacOS 默认通常无 JSON 文件或CLAUDE_CODE_OAUTH_TOKEN环境变量由claude setup-token设置OpenCode可选导入源~/.local/share/opencode/auth.jsonpi可选导入源~/.pi/agent/auth.jsonJ-Code OpenAI/Codex OAuth~/.jcode/openai-auth.jsonCodex CLI 认证源确认后原位读取~/.codex/auth.jsonGemini 原生 OAuth~/.jcode/gemini_oauth.jsonGemini CLI 导入回退~/.gemini/oauth_creds.jsonCopilot CLI 明文回退~/.copilot/config.json遗留 Copilot JSON 来源~/.config/github-copilot/hosts.json、~/.config/github-copilot/apps.json从源码结构看上述认证逻辑集中在 crates/jcode-base/src/auth/ 目录oauth.rs承载 PKCE 与本地回环回调服务器claude.rs、codex.rs、azure.rs、gemini.rs、google.rs、copilot.rs、antigravity.rs分别实现各 provider 的凭证解析与刷新运行时 provider 实现则在 crates/jcode-base/src/provider/ 下。ClaudeClaude MaxOAuth登录步骤推荐使用内置 OAuth 流程步骤如下运行jcode login --provider claude推荐或运行jcode login后在交互选择器中选中 Claude。无头环境 / SSH 场景jcode login --provider claude --no-browser可脚本化远程流程jcode login --provider claude --print-auth-url之后用--callback-url或--auth-code完成登录替代方案先运行claude或claude setup-token。jcode 可以检测 Claude Code 的凭证读取前询问用户并记住该信任决定供后续会话使用。这适用于 Claude Code 将凭证存储在~/.claude/.credentials.jsonLinux/Windows、macOS 登录 KeychainClaude Code-credentials或CLAUDE_CODE_OAUTH_TOKEN环境变量的场景。在 macOS 上批准 Keychain 来源后jcode 会把凭证复制到~/.jcode/auth.json一次之后会话不再反复访问 Keychain。验证登录jcode --provider claude run Say hello from jcode。凭证发现顺序为~/.jcode/auth.json~/.claude/.credentials.json已批准的 Claude Code 原生凭证macOS KeychainClaude Code-credentials或CLAUDE_CODE_OAUTH_TOKEN环境变量~/.local/share/opencode/auth.json~/.pi/agent/auth.json从源码看Claude 凭证的解析兼容两种expiresAt格式Claude Code 的 JSON 文件存 epoch 毫秒macOS Keychain blob 存 RFC 3339 字符串解析器同时接受两者见 crates/jcode-base/src/auth/claude.rs 中的deserialize_expires_at。同时auth.json支持多账户结构anthropic_accountsactive_anthropic_account并向后兼容旧的单账户{anthropic: {...}}布局。直接 Anthropic API默认路径--provider claude默认走直接 Anthropic Messages API。jcode 拥有完整的运行时路径认证、刷新、请求整形、工具兼容性与传输全部自管。这意味着 Claude OAuth 登录后并不依赖 Claude Code CLI 进程。Claude OAuth 直接 API 兼容OAuth 合同Claude Code 的 OAuth token 可以直连 Messages API但前提是请求满足 Claude Code 的 “OAuth 合同”。jcode 在默认 Claude 运行时路径上自动应用这些行为使用 Messages 端点并携带?betatrue发送User-Agent: claude-cli/1.0.0发送anthropic-beta: oauth-2025-04-20,claude-code-20250219在系统块最前面插入 Claude Code 身份行作为第一个块You are Claude Code, Anthropics official CLI for Claude.工具名称白名单Claude OAuth 请求会拒绝某些工具名。jcode 将一小部分内置工具名在线路上重映射为 Claude Code 的内置名称并在响应时映射回来保证原生工具继续可用其余工具以原名转发因此完整的自定义工具集websearch、webfetch、browser、codesearch、memory、swarm、multiedit、open 等在 OAuth 模式下保持可用。重映射关系为jcode 本地工具名Claude OAuth 线上名称bashBashreadReadwriteWriteeditEditglobGlobgrepGrepsubagentAgentscheduleScheduleWakeupskill_manageSkill实现细节可在 crates/jcode-provider-anthropic/src/lib.rs 中看到OAUTH_BUILTIN_LOCAL_TOOLS常量列出subagent、bash、edit、glob、grep、read、skill_manage、writeformat_tools(is_oauth, ...)在 OAuth 模式下为这些本地工具生成“手调”的 Claude-Code 内置工具定义如Agent、Bash、Edit、Glob、Grep的手写 schema因为 Anthropic 订阅端点期望内置名称配合兼容 schema未在此列出的工具则从真实注册表追加从而保留完整工具集。值得注意的是schedule被刻意排除在手调列表外其旧的ScheduleWakeupschema 曾与真实工具漂移广告了delaySeconds/reason/prompt而处理器要求taskwake_in_minutes/wake_at导致所有调用都失败issue #706因此现在把真实 schema 用重映射名原样转发从构造上保证二者同步。注意事项OAuth token 过期后通过 Claude OAuth refresh 端点刷新即可。缺少身份行或白名单工具名时即使 token 本身有效API 也会拒绝 OAuth 请求。已弃用的 Claude CLI 传输旧的 Claude CLI shell-out 路径已弃用仅用于遗留兼容。仍可临时强制启用JCODE_USE_CLAUDE_CLI1或--provider claude-subprocess已弃用的隐藏兼容值控制该已弃用传输的环境变量如下环境变量默认值JCODE_CLAUDE_CLI_PATHclaudeJCODE_CLAUDE_CLI_MODELclaude-opus-4-5-20251101JCODE_CLAUDE_CLI_PERMISSION_MODEbypassPermissionsJCODE_CLAUDE_CLI_PARTIAL设置为0可禁用部分流式从 src/cli/login.rs 的登录入口可以看到选择 Claude subprocess 时仍会输出弃用警告“Claude subprocess transport is deprecated and will be removed. Direct Anthropic API is already the default for--provider claude.”OpenAI / Codex OAuth登录步骤运行jcode login --provider openai。无头 / SSHjcode login --provider openai --no-browser可脚本化远程流程jcode login --provider openai --print-auth-url之后用--callback-url完成除非使用--no-browser浏览器会打开 OpenAI OAuth 页面。本地回调默认监听http://localhost:1455/auth/callback。若端口1455被占用jcode 回退到手动粘贴流程你可以粘贴完整回调 URL 或查询字符串。登录后 token 保存在~/.jcode/openai-auth.json。凭证发现顺序为~/.jcode/openai-auth.json~/.codex/auth.json受信任的 OpenCode/pi OAuth~/.local/share/opencode/auth.json/~/.pi/agent/auth.jsonOPENAI_API_KEY若 jcode 在~/.codex/auth.json发现已有凭证会先询问再读取批准后记住该信任决定并且不移动、删除或重写 Codex 文件。从源码看OpenAI 的 OAuth 配置客户端 ID、授权端点、token 端点、默认端口 1455、回调路径/auth/callback、scopes集中在 crates/jcode-base/src/auth/oauth.rs 的pub mod openai中PKCE 的 code verifier/challenge 与 CSRF state 也由该文件生成。请求细节J-Code 使用Responses API。若存在 ChatGPT 订阅refresh token 或 id_token请求发往https://chatgpt.com/backend-api/codex/responses并携带请求头originator: codex_cli_rschatgpt-account-id: from token否则使用https://api.openai.com/v1/responsesAPI-key 模式无 ChatGPT/Codex OAuth下Responses API 基础 URL 可被覆盖以便指向本地或代理的 Responses-API 端点。按以下顺序检查任一设置为以 API 版本结尾的绝对http(s)://基础即可例如http://127.0.0.1:8317/v1JCODE_OPENAI_API_BASEOPENAI_BASE_URLOPENAI_API_BASEjcode 会自行追加/responses并从同一 base 推导 WebSocket 与/compact端点同时让/models目录探测也指向该 base。此覆盖在 ChatGPT/Codex OAuth 模式下被忽略该后端固定格式错误的值只会被记录并忽略不会破坏请求。TroubleshootingClaude 401/认证错误运行jcode login --provider claude。401/403重新运行jcode login --provider openai。回调问题确保端口 1455 空闲且浏览器可访问http://localhost:1455/auth/callback。Azure OpenAIAzure 支持是在 J-Code 与 OpenCode/Crush 对比后加入的。当时判定有意义的认证缺口并非另一种浏览器 OAuth 流程而是对Azure OpenAI的支持采用两种方式之一Microsoft Entra ID凭证通过 Azure 的DefaultAzureCredential链或Azure OpenAI API keys。登录 / 设置步骤运行jcode login --provider azure。输入 Azure OpenAI 端点例如https://your-resource.openai.azure.com。输入 Azure deployment/model 名称。选择认证模式Entra ID推荐或API key。jcode 将设置保存到~/.config/jcode/azure-openai.env。存储配置Azure env 文件可能包含AZURE_OPENAI_ENDPOINTAZURE_OPENAI_MODELAZURE_OPENAI_USE_ENTRAAZURE_OPENAI_API_KEY仅在使用 key 认证时运行时行为jcode 将端点规范化为较新的 Azure OpenAI/openai/v1base。Entra ID 模式下jcode 使用azure_identity::DefaultAzureCredential获取 bearer tokenscope 为https://cognitiveservices.azure.com/.default。API key 模式下jcode 以 Azure 风格api-key请求头发送凭证。Azure provider 当前在底层复用 J-Code 的 OpenAI 兼容传输层实现位于 crates/jcode-base/src/provider/openrouter.rs。Azure 默认禁用模型目录抓取因此应显式配置 deployment/model。Entra ID 凭证来源DefaultAzureCredential可以从以下来源解析凭证az loginmanaged identity托管身份Azure 环境凭证Troubleshooting本地 Entra ID 认证失败先尝试az login。确保你的身份对 Azure OpenAI 资源有访问权限。请求报 deployment/model 错误核对AZURE_OPENAI_MODEL与部署模型名一致。若偏好静态凭证重新运行jcode login --provider azure并选择 API key 模式。Gemini OAuth登录步骤运行jcode login --provider gemini或在 TUI 内执行/login gemini。无头 / SSHjcode login --provider gemini --no-browser可脚本化远程流程jcode login --provider gemini --print-auth-url之后用--auth-code完成除非使用--no-browserjcode 会打开浏览器进入 Gemini Code Assist 所用的 Google OAuth 流程。若本地回调绑定不可用jcode 回退到使用https://codeassist.google.com/authcode的手动粘贴流程。token 保存在~/.jcode/gemini_oauth.json。凭证发现顺序jcode 原生 Gemini token~/.jcode/gemini_oauth.jsonGemini CLI OAuth 来源批准后只读~/.gemini/oauth_creds.json受信任的 OpenCode/pi OAuth~/.local/share/opencode/auth.json/~/.pi/agent/auth.json运行时说明jcode 使用原生 Google OAuth直接与 Google Code Assist 后端通信。过期 token 使用 Google refresh token 自动刷新。部分学校 / Workspace 账户可能需要为 Code Assist 资格检查设置GOOGLE_CLOUD_PROJECT或GOOGLE_CLOUD_PROJECT_ID。Troubleshooting浏览器启动失败使用--no-browser并走粘贴回调/授权码流程。Workspace 账户资格或引导失败设置GOOGLE_CLOUD_PROJECT后重试。登录成功但后续请求失败重新运行jcode login --provider gemini刷新存储的会话。认证验证auth-test登录后可使用内置认证验证器测试完整的本地认证/运行时路径# 先执行 Gemini 登录再验证 token 刷新与 provider 冒烟测试 jcode --provider gemini auth-test --login # 验证已有 Gemini 认证不重新登录 jcode --provider gemini auth-test # 检查所有当前已配置的支持认证 provider jcode auth-test --all-configured对模型 providerauth-test会依次执行凭证发现credential discovery刷新 / 认证探测refresh/auth probe真实 provider 冒烟提示期望返回AUTH_TEST_OK使用与正常对话相同的工具附加请求路径进行工具冒烟提示仅需认证/简单运行时检查时可使用--no-tool-smoke。对 Gmail/Google它只验证凭证发现与 token 刷新跳过模型冒烟因为不是模型 provider。从源码看auth-test的完整流水线在 src/cli/auth_test/run.rsrun_auth_test_command负责目标解析、populate_auth_test_target_report依次执行凭证探测与两类冒烟maybe_run_auth_test_smoke以输出是否包含AUTH_TEST_OK判定成功--all-configured通过crate::auth::AuthStatus::check_fast()快速发现所有已配置 provider。OpenAI 兼容 API-key providerJ-Code 为许多 OpenAI 兼容 API 内置了一等公民的 provider 预设统一使用同一套内置登录流程模式jcode login --provider name。对于任意 OpenAI 兼容 API尤其是 Agent 正在做初始化配置时建议使用命名 profile 命令而非手改配置printf %s $MY_API_KEY | jcode provider add my-api \ --base-url https://llm.example.com/v1 \ --model my-model-id \ --api-key-stdin \ --set-default \ --json jcode --provider-profile my-api auth-test --no-tool-smoke该命令在~/.jcode/config.toml写入[providers.my-api]并把 key 存到 jcode 的私有应用配置目录例如~/.config/jcode/provider-my-api.env。对 localhost 服务器可使用--no-api-key。值得注意的预设 provider 包括Fireworks登录jcode login --provider fireworks存储 env 文件~/.config/jcode/fireworks.envAPI key 环境变量FIREWORKS_API_KEYBase URLhttps://api.fireworks.ai/inference/v1默认模型提示accounts/fireworks/routers/kimi-k2p5-turboNovita AI登录jcode login --provider novita或在 TUI 中/login novita认证方式按量付费 API key非订阅登录或浏览器 OAuth存储 env 文件~/.config/jcode/novita.envAPI key 环境变量NOVITA_API_KEYBase URLhttps://api.novita.ai/openai默认模型提示zai-org/glm-5.3MiniMax登录jcode login --provider minimax存储 env 文件~/.config/jcode/minimax.envAPI key 环境变量OPENAI_API_KEYBase URLhttps://api.minimax.io/v1默认模型提示MiniMax-M2.7以上均为 jcode 一等公民的 provider 预设而非手工自定义端点示例。当没有内置预设时仍可用openai-compatible对接任意自定义 provider。如果 jcode 在受信任的 OpenCode/pi 认证文件中发现匹配的 API key它可以直接复用于对应的 provider 预设无需再次粘贴 key。provider 元数据与登录描述符定义在 crates/jcode-provider-metadata/src/lib.rs。实验性 CLI ProviderJ-Code 还支持实验性的 CLI-backed provider以及带原生 OAuth 登录的 Antigravity--provider cursor--provider copilot--provider antigravity其中 Cursor 使用 jcode 的原生 HTTPS 传输Copilot 使用 GitHub device-flow 认证Antigravity 的登录/认证存储由 jcode 原生处理。Cursor登录jcode login --provider cursor保存CURSOR_API_KEY到~/.config/jcode/cursor.env运行时jcode 使用原生 HTTPS 请求若配置了 Cursor API keyjcode 直接交换/使用它环境变量JCODE_CURSOR_MODEL默认composer-1.5CURSOR_API_KEY可选覆盖已保存的 key从 src/cli/auth_test/run.rs 可以看到Cursor 的 tool smoke 会被跳过——其原生 agent 传输是纯文本的不通过agent.v1.AgentService/Run暴露工具调用基础 provider smoke 仍可验证对话能力。GitHub Copilot登录jcode login --provider copilot无头 / SSHjcode login --provider copilot --no-browser可脚本化远程流程jcode login --provider copilot --print-auth-url之后jcode login --provider copilot --completejcode 使用 GitHub device code flow无需打开本地浏览器即可打印验证 URL/QR 码凭证发现顺序COPILOT_GITHUB_TOKENGH_TOKENGITHUB_TOKEN受信任的~/.copilot/config.json受信任的遗留~/.config/github-copilot/hosts.json受信任的遗留~/.config/github-copilot/apps.json受信任的 OpenCode/pi OAuth 条目gh auth token环境变量JCODE_COPILOT_CLI_PATHCLI 路径的可选覆盖JCODE_COPILOT_MODEL默认claude-sonnet-4Antigravity登录jcode login --provider antigravity原生 Google OAuth 流程不需要安装 Antigravity无头 / SSHjcode login --provider antigravity --no-browser可脚本化远程流程jcode login --provider antigravity --print-auth-url之后用--callback-url完成Token~/.jcode/antigravity_oauth.json凭证发现顺序~/.jcode/antigravity_oauth.json中的原生 jcode token存在时使用受信任的 OpenCode/pi OAuth 条目运行时jcode 自行认证并存储/刷新 Antigravity OAuth token若选择--provider antigravityprovider 传输仍会为补全而 shell-out 到 Antigravity CLI环境变量JCODE_ANTIGRAVITY_CLIENT_IDOAuth client id 的可选覆盖JCODE_ANTIGRAVITY_CLIENT_SECRETOAuth client secret 的可选覆盖JCODE_ANTIGRAVITY_VERSIONAntigravity 请求指纹/版本的可选覆盖JCODE_ANTIGRAVITY_CLI_PATH默认antigravity仅运行时JCODE_ANTIGRAVITY_MODEL默认defaultJCODE_ANTIGRAVITY_PROMPT_FLAG默认-pJCODE_ANTIGRAVITY_MODEL_FLAG默认--modelGoogle / Gmail OAuth登录步骤运行jcode login --provider google。无头 / SSHjcode login --provider google --no-browser凭证已配置后的可脚本化远程流程jcode login --provider google --print-auth-url若 Google 凭证尚未配置jcode 会先引导你保存 client ID/client secret或导入 JSON 凭证文件。可脚本化 Google 流程中如不想用默认的 full 访问层级可用--google-access-tier full|readonly选择 Gmail scope。之后用jcode login --provider google --callback-url full callback url or query完成已打印的流程。说明Google/Gmail 可脚本化认证要求先保存 OAuth client 凭证。回调 URL 可以来自在 loopback 重定向上失败的远程浏览器会话从地址栏复制最终 URL粘贴或传回给 jcode 即可。可脚本化认证的状态生命周期可脚本化登录流程--print-auth-url/--callback-url/--auth-code/--complete/--flow-id/--cancel由 src/cli/login/scriptable.rs 实现其生命周期要点如下jcode 将临时可脚本化登录状态存储在~/.jcode/pending-login/*.json。pending 状态自动过期默认 30 分钟见 src/cli/login.rs 中default_expires_at_ms的current_time_ms() 30 * 60 * 1000。过期的 pending 条目在可脚本化登录流程开始或恢复时被清理cleanup_stale_pending_login_files。Copilot 的--print-auth-url存储 GitHub device code 会话--complete稍后恢复轮询。额外细节--flow-id必须为 1–64 个 ASCII 字母、数字、下划线或连字符parse_login_flow_id--cancel需要--flow-id且不能与登录开始/完成标志混用带--flow-id的 pending 状态存储在pending-login/flows/flow-id/下并带锁文件取消会写入 30 分钟 TTL 的.cancelled标记来阻止迟到的 begin 写入。所有 pending 与凭证文件均通过harden_secret_file_permissions收紧权限--json输出保持机器可读QR 码只出现在 stderr 供人类无头登录使用。小结J-Code 的认证体系覆盖了“自带登录流程 复用已有凭证 兼容任意 OpenAI 端点”三个层次Claude、OpenAI、Gemini、Google、Antigravity 提供原生 OAuthAzure OpenAI 支持 Entra ID 与 API keyCopilot 走 GitHub device flowFireworks、Novita AI、MiniMax 及任意 OpenAI 兼容服务通过 API key 预设或命名 profile 接入。所有外部凭证在被读取前都会征求用户同意、原文件保持不动、对称链接被拒绝信任决定跨会话记忆。日常使用中jcode login --provider name完成登录jcode auth-test含--all-configured与--no-tool-smoke即可对整个本地认证/运行时路径做端到端验证——这两条命令构成了排查一切认证问题的基础工作流。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表