Codex 源码解析 · 第 6 讲
Codex 源码解析系列 第 6 讲：Login/Auth 登录与凭证管理 基于 OpenAI Codex 源码 · 2026-09-30 💡 本讲一句话： Codex 的登录是一条跑在 localhost 上的完整 OAuth 授权码流程——浏览器去 auth.openai.com 换 token，但凭证的读写全在 codex-login crate 里：8 种凭证统一成一个枚举、4 种存储后端自动降级、到期前主动刷新 + 永久失败分类。读完这一讲，你知道自己的 token 存在哪、为什么不会泄露、过期了怎么续。 一、codex-login：一个 crate 管完所有凭证 第 5 讲我们看过 ModelProvider::auth() 返回的是 CodexAuth ——那只是消费方视角。这一讲钻进生产方： codex-login crate（约 8K 行），它负责登录、存储、刷新、吊销四件事。文件地图： 🔹 auth/manager.rs （3090 行）：CodexAuth 枚举 + AuthManager + 刷新逻辑，全 crate 的核心 🔹 auth/storage.rs （548 行）：auth.json 结构 + File/Keyring/Auto/Ephemeral 四种存储后端 🔹 server.rs （1318 行）：本地 OAuth 回调服务器 + token 交换 🔹 pkce.rs / token_data.rs / auth/revoke.rs ：PKCE、JWT claims 解析、登出吊销 先看最顶层的类型——所有登录方式最后都收敛到这一个枚举： 📄 codex-rs/login/src/auth/manager.rs (第 79-89 行) /// Authentication mechanism used by the current user. // 文档注释：当前用户使用的认证机制——这个枚举就是全 Codex 的凭证总入口 pub enum CodexAuth { // 8 种登录方式共用一个类型，上层调用方永远只面对它，不需要知道具体是哪种 ApiKey(ApiKeyAuth), // 裸 API key（OPENAI_API_KEY / config）——最简单形态，静态、无需刷新 Chatgpt(ChatgptAuth), // 浏览器 OAuth 交互登录：持有存储后端 + HTTP client，能自己刷新 token ChatgptAuthTokens(ChatgptAuthTokens), // 外部注入的 ChatGPT token（app-server 场景）：只有状态、不拥有存储 Headers(AuthHeaders), // 外部系统直接给的自定义请求头——永不落盘，只活在内存里 AgentIdentity(AgentIdentityAuth), // Agent 身份：JWT 或 runtime_id+私钥对，托管 agent 场景专用（第 7 讲细拆） PersonalAccessToken(PersonalAccessTokenAuth), // PAT 个人访问令牌：长效凭证，不走 OAuth 刷新流程 BedrockApiKey(BedrockApiKeyAuth), // Amazon Bedrock API key——静态密钥 BedrockAccessKeys(BedrockAccessKeysAuth), // AWS AK/SK：可以现场签 STS token，是少数"能自己续命"的静态凭证之一 } // 枚举结束：新增登录方式 = 加一个变体 + 在 from_auth_dot_json / auth_mode 里补分支 为什么这样设计： 把"凭证是什么"和"凭证怎么来"解耦。注意 Chatgpt （拥有存储、可刷新）和 ChatgptAuthTokens （纯状态快照）是两个变体——前者是 CLI 自己登录的结果，后者是 app-server 这类宿主进程把 token 喂进来的结果。两者对 API 调用方完全等价（ auth_mode() 都归一成 AuthMode::Chatgpt ），但生命周期管理完全不同：一个要刷新、一个只能等宿主重新…
阅读全文：Codex 源码解析 第 6 讲