Codex 认证：为开发者保障 OpenAI 访问安全

简化 Codex 认证：开发者指南

OpenAI 的 Codex，一个用于代码生成和理解的强大 AI 模型，已成为开发者不可或缺的工具。随着其功能扩展到各种界面——从专用应用程序和 IDE 扩展到命令行界面 (CLI)——了解其认证机制对于安全高效的工作流集成至关重要。本文深入探讨了 Codex 的核心认证方法，探索其细微差别、安全隐患以及开发者和管理员的最佳实践。

无论您是想利用 Codex 进行快速原型开发，将其集成到您的 CI/CD 管道中，还是在企业环境中管理其部署，掌握 Codex 认证 过程都是第一步。

选择您的 Codex 登录方法：ChatGPT 与 API 密钥

OpenAI Codex 在与其底层 OpenAI 模型交互时提供两种不同的认证路径，每种都针对不同的用例量身定制，并提供独特的优势：

使用 ChatGPT 登录：此方法将您的 Codex 使用情况连接到您现有的 ChatGPT 订阅。它是 Codex 云端环境所需的登录方式，并提供“快速模式”等特定功能，这些功能依赖于 ChatGPT 积分。当您以这种方式进行认证时，您的使用将受您的 ChatGPT 工作区权限、基于角色的访问控制 (RBAC) 以及您已设置的任何 ChatGPT 企业版保留和驻留设置的管辖。该过程通常涉及基于浏览器的登录流程，在返回访问令牌给您的 Codex 客户端（应用程序、CLI 或 IDE 扩展）之前，会将您重定向以完成认证。
使用 API 密钥登录：对于需要对使用量和计费进行更精细控制，或需要编程访问的开发者，使用 API 密钥是首选途径。API 密钥可从您的 OpenAI 控制台获取，它将您的 Codex 使用情况直接链接到您的 OpenAI Platform 账户。计费按标准 API 费率进行，数据处理遵循您的 API 组织的数据保留和数据共享设置。此方法特别推荐用于自动化工作流，例如持续集成/持续部署 (CI/CD) 作业，在这些场景下，直接的用户交互式登录不切实际。然而，依赖 ChatGPT 积分的功能可能无法通过 API 密钥认证获得。

值得注意的是，虽然 Codex CLI 和 IDE 扩展都支持这两种方法，但 Codex 云端界面强制要求使用 ChatGPT 登录。

以下是这两种方法的快速比较：

功能	使用 ChatGPT 登录	使用 API 密钥登录
主要用例	交互式使用，Codex 云端，订阅功能	编程访问，CI/CD，按使用量计费
计费模式	ChatGPT 订阅 / 积分	标准 OpenAI Platform API 费率
数据治理	ChatGPT 工作区权限，RBAC，企业设置	OpenAI Platform API 组织数据设置
功能	访问 '快速模式' (ChatGPT 积分)	完整的 API 访问，无 '快速模式'（使用标准计费）
支持的接口	Codex 应用程序，CLI，IDE 扩展，Codex 云端	Codex 应用程序，CLI，IDE 扩展（非 Codex 云端）
安全建议	强烈建议 MFA，某些情况下强制执行	切勿在不受信任的环境中泄露 API 密钥

使用 MFA 保护您的 Codex 云账户

鉴于 Codex 直接与您的代码库交互，其安全要求往往超过其他 ChatGPT 功能。多因素认证 (MFA) 是您 Codex 云账户的关键保障。

如果您使用社交登录提供商（例如 Google、Microsoft、Apple），您可以通过其各自的安全设置启用 MFA。对于使用电子邮件和密码登录的用户，在访问 Codex 云端之前，必须在您的账户上设置 MFA。即使您的账户支持多种登录方法，并且其中一种是电子邮件/密码，也必须配置 MFA。

受益于单点登录 (SSO) 的企业用户应依靠其组织的 SSO 管理员来强制所有用户使用 MFA，从而在整个范围内建立一致且强大的安全态势。这种积极的措施显著降低了未经授权访问您的开发环境和知识产权的风险。

管理登录缓存和凭据存储

为了用户便利，Codex 会在本地缓存您的登录详细信息。无论您是使用 ChatGPT 登录还是 API 密钥，Codex 应用程序、CLI 和 IDE 扩展都会共享这些缓存的凭据。这意味着一旦认证成功，您通常无需在后续会话中再次登录。但是，从一个界面注销将使共享会话失效，需要重新认证。

Codex 将这些凭据存储在以下两个位置之一：

~/.codex/auth.json（或 CODEX_HOME 目录）中的纯文本文件。
您操作系统的原生凭据存储。

您可以使用 cli_auth_credentials_store 设置配置 Codex CLI 存储这些凭据的位置，可在 "file"（文件）、"keyring"（OS 凭据存储）或 "auto"（自动，首先尝试 keyring，然后回退到 file）之间进行选择。

安全最佳实践：如果您选择基于文件的存储，请像对待敏感密码一样，极其小心地对待 ~/.codex/auth.json。它包含可能导致未经授权访问的访问令牌。切勿将此文件提交到版本控制，粘贴到公共论坛，或通过聊天分享。 为了增强安全性，通常建议使用 keyring 选项，因为它利用了操作系统内置的更安全的凭据管理。

适用于企业的进阶认证管理

对于跨多个团队部署 Codex 的组织，强大的管理控制对于维护安全和合规性至关重要。OpenAI 提供了帮助管理员强制执行特定登录方法和工作区限制的功能。

管理员可以使用 forced_login_method 等设置，强制管理环境中的所有用户必须使用 "chatgpt" 或 "api" 密钥登录。这确保了对内部安全策略或计费模型的遵守。此外，对于基于 ChatGPT 的登录，forced_chatgpt_workspace_id 设置允许管理员将用户限制到特定的、经批准的 ChatGPT 工作区。

这些控制通常通过托管配置而非个人用户设置应用，确保策略执行的一致性。如果用户的活动凭据不符合配置的限制，Codex 将自动将其注销并退出，从而维护托管环境的完整性。

无头设备登录和自定义 CA 捆绑包

开发者通常在多样化的环境中工作，包括没有图形浏览器界面的远程服务器或无头机器。当使用 Codex CLI 时，如果标准基于浏览器的登录 UI 存在问题（例如，由于无头环境或网络阻塞），OpenAI 提供了替代方案。

设备代码认证（目前处于测试阶段）是此类场景的首选解决方案。在您的 ChatGPT 安全设置（个人或工作区管理员）中启用此功能后，您可以在交互式 CLI 登录中选择“使用设备代码登录”或直接运行 codex login --device-auth。这将生成一个代码，您可以在独立的、支持浏览器的设备上输入该代码以完成登录，从而无需本地浏览器即可确保安全访问。

对于在企业 TLS 代理后面运行或使用私有根证书颁发机构 (CA) 的组织，安全通信通常需要自定义 CA 捆绑包。Codex 适应了这一点，允许您在登录前将 CODEX_CA_CERTIFICATE 环境变量设置为您的 PEM 捆绑包的路径。这确保了所有安全连接——包括登录、HTTPS 请求和 WebSocket 连接——都信任您的企业 CA，从而在您的基础设施中保持合规性和安全性。您可以在 Codex 提示指南等资源中找到有关在安全环境中连接 AI 模型的通用最佳实践的更多详细信息。

通过理解和正确实施这些认证和安全功能，开发者和企业可以自信地将 OpenAI Codex 集成到他们的工作流中，在利用其强大功能的同时，保持对访问和数据的严格控制。

原始来源

https://developers.openai.com/codex/auth/

常见问题

What are the primary authentication methods for OpenAI Codex, and what are their key differences?

OpenAI Codex offers two main authentication methods: 'Sign in with ChatGPT' and 'Sign in with an API key.' Signing in with ChatGPT grants access based on your existing ChatGPT subscription, applying your workspace permissions, RBAC, and ChatGPT Enterprise data retention/residency settings. This method is required for Codex cloud and provides access to features like 'fast mode' powered by ChatGPT credits. Conversely, signing in with an API key provides usage-based access, billed through your OpenAI Platform account at standard API rates. This method follows your API organization’s data-sharing settings and is recommended for programmatic workflows like CI/CD jobs, offering greater flexibility and granular control over usage. While the CLI and IDE extension support both, Codex cloud exclusively requires ChatGPT sign-in.

Why is Multi-Factor Authentication (MFA) considered crucial for securing a Codex cloud account, and how can users enable it?

Multi-Factor Authentication (MFA) is crucial for securing Codex cloud accounts because Codex interacts directly with sensitive codebase, necessitating robust security measures beyond standard ChatGPT features. MFA adds an essential layer of protection by requiring a second form of verification, significantly reducing the risk of unauthorized access even if a password is compromised. Users can enable MFA via their social login provider (Google, Microsoft, Apple) if they use one. If logging in with email and password, MFA *must* be set up on the account before accessing Codex cloud. Enterprise users accessing via Single Sign-On (SSO) should have MFA enforced by their organization's SSO administrator, ensuring comprehensive security across the development environment.

How does Codex manage and store login credentials, and what are the security best practices for handling them?

Codex caches login details locally, either in a plaintext file at `~/.codex/auth.json` or within your operating system's native credential store. The CLI and IDE extension share these cached credentials for convenience. For sign-in with ChatGPT, active sessions automatically refresh tokens to maintain continuity. Users can control storage location using the `cli_auth_credentials_store` setting, choosing 'file', 'keyring' (OS credential store), or 'auto'. When using file-based storage, it is critical to treat `~/.codex/auth.json` with the same care as a password: never commit it to version control, paste it into public forums, or share it in chat, as it contains sensitive access tokens. The 'keyring' option is generally more secure as it leverages OS-level protection.

What administrative controls are available for managing Codex authentication in managed environments, and how are they applied?

In managed environments, administrators can enforce specific authentication policies for Codex users through configuration settings. The `forced_login_method` parameter can restrict users to either 'chatgpt' or 'api' key login, ensuring compliance with organizational security or billing policies. Additionally, for ChatGPT logins, the `forced_chatgpt_workspace_id` setting allows administrators to restrict users to a particular ChatGPT workspace, enhancing governance and data segregation. These settings are typically applied via managed configuration, rather than individual user setups, ensuring consistent policy enforcement across the enterprise. If a user's active credentials don't match the enforced restrictions, Codex will automatically log them out and exit, maintaining a secure and controlled environment.

What options exist for logging into the Codex CLI on headless devices or in environments where the browser-based UI is problematic?

For scenarios involving headless devices, remote environments, or local networking configurations that block the OAuth callback, Codex offers alternative login methods for its CLI. The preferred method is 'device code authentication' (currently in beta). To use this, users must first enable device code login in their ChatGPT security settings (personal account) or workspace permissions (for administrators). Then, when interacting with the CLI, they can choose 'Sign in with Device Code' from the interactive UI or directly run `codex login --device-auth`. This method provides a code that can be entered on a separate device with a browser, allowing authentication without a local browser UI. If device code authentication is not feasible, fallback methods might involve manual token pasting or configuration adjustments as guided by support.

How does the choice of authentication method (ChatGPT vs. API Key) impact data handling and retention policies in Codex?

The chosen authentication method significantly dictates the data handling and retention policies applied to your Codex usage. When you 'Sign in with ChatGPT,' your Codex activities adhere to the data-handling policies, RBAC (Role-Based Access Control), and enterprise retention and residency settings configured for your ChatGPT workspace. This ensures consistency with your established ChatGPT Enterprise agreement. Conversely, if you 'Sign in with an API key,' your usage follows the data retention and sharing settings established for your OpenAI Platform API organization. This distinction is crucial for organizations requiring specific compliance or data governance frameworks, as it determines how your code interactions and other data generated by Codex are processed and stored by OpenAI.

Can Codex be used with custom CA bundles for secure communication over corporate networks?

Yes, Codex supports the use of custom CA bundles, which is essential for environments operating behind corporate TLS proxies or utilizing private root CAs. To enable this, users need to set the `CODEX_CA_CERTIFICATE` environment variable to the path of their PEM bundle before initiating a login or any other Codex operation. If `CODEX_CA_CERTIFICATE` is not set, Codex will default to using `SSL_CERT_FILE`. This custom CA setting uniformly applies across all secure communication channels, including the login process, standard HTTPS requests, and secure websocket connections, ensuring that all data exchanges comply with the corporate network's security policies and are properly trusted within the organizational infrastructure.

保持更新

将最新AI新闻发送到您的收件箱。