Sign in with ChatGPT 是 OpenAI 的 OAuth 2.0 与 OpenID Connect 登录,面向全球 ChatGPT 用户开放。你的应用会获得一个稳定的账号 ID,以及用户的姓名、邮箱地址和头像。自 2026 年 9 月 29 日的 DevDay 起,Plus 和 Pro 用户还可以让已接入的应用用他们的 ChatGPT 套餐(而不是你的 API key)来运行 AI 请求,额度上限由用户按应用设置的每周上限决定。你的应用永远不会拿到他们的对话、记忆或 API key。
第二部分会影响你的账单。本文介绍整个流程、用户视角下的套餐用量、目前谁能接入、什么时候应该用用户的套餐替代你的 key,以及如何在 Apifox 中测试登录及其失败路径。关于本次活动的其他内容,参见 DevDay 2026 汇总;如果分不清身份认证与授权的区别,可以先读 OAuth vs OpenID。
Sign in with ChatGPT 速览
| 项目 | OpenAI 的说明 |
|---|---|
| 身份 scope | openid profile email |
| 套餐用量 scope(开源流程) | offline_access resource.invoke chatgpt.tokens.use.direct,并带上 resource=https://api.openai.com/v1 |
| 你的应用获得 | 一个 ID token;使用套餐用量时,还会获得 access token 和 refresh token |
| 套餐用量资格 | Plus 和 Pro,且需在已接入的应用中 |
| 用量计入哪里 | 计入套餐的 ChatGPT Work 和 Codex 用量 |
| 按应用控制 | 每周上限按整体每周用量的百分比设置;超出上限后使用 credits 默认关闭 |
| 套餐用量的 token | access token 1 小时;refresh token 30 天,每次刷新都会更换 |
| 开发者接入 | 商业应用:通过意向表单获得的有限试用。开源应用:自助接入 |
来源:Sign in with ChatGPT 文档、token 参考,以及 OpenAI 的帮助文章 在其他应用中使用你的 ChatGPT 套餐。
你的应用能获得什么,不能获得什么
默认只涉及身份认证。请求 openid profile email 的客户端会获得一个 ID token。根据 网站指南,profile 涵盖可用的 claims,例如姓名和头像,email 涵盖邮箱和邮箱验证相关的 claims。身份 scope 不会授予对 ChatGPT 对话或 OpenAI API 资源的访问权限。
请用经过验证的 sub 加上 issuer 和 client ID 作为账号的唯一标识,而不是邮箱。OpenAI 提醒说,仅凭邮箱匹配不足以证明账号归属,所以要请已有用户确认关联。
套餐用量是一项单独的授权。如果用户批准了额外的 scope,token 响应中会多出一个用于合格的 Responses API 请求的 access token。纯身份认证的客户端不应该要求 access_token,因为 id_token 才是唯一必需的产物。
OAuth 流程如何运作
网站流程是标准的 Authorization Code 授权模式加 PKCE,再加 OIDC。从 https://auth.openai.com/.well-known/openid-configuration 加载各接口地址。文档列出的生产环境取值如下:
Issuer: https://auth.openai.com
Authorization endpoint: https://auth.openai.com/api/accounts/authorize
Token endpoint: https://auth.openai.com/api/accounts/oauth/token
JWKS URI: https://auth.openai.com/.well-known/jwks.json
- 你的后端会生成一个新的
state、一个带 S256 challenge 的 PKCE verifier,以及一个nonce。 - 它把浏览器重定向到 authorization 接口,并带上你的 client ID、精确的 redirect URI 和 scope。
- 用户同意后,OpenAI 会把 code 返回给你的回调地址。
- 你的后端校验
state、用 code 换取 token,并验证 ID token 的签名、issuer、audience、有效期和 nonce。 - 它会查找、创建或关联本地账号,并签发自己的会话。
公共客户端不发送密钥。使用 client_secret_basic 的机密客户端只在 HTTP Basic header 中发送密钥。
开源工具的注册方式不同。开源登录指南 的起点是 client_id=dynamic_agent_client、agent_name_hint 设为你的应用名,以及每个主机一个持久化的 ext_agent_host_id。回调会返回一个签发的 client ID(例如 oaiapp_...)供你保存并复用;重定向地址是一个 127.0.0.1 环回地址,不涉及 client secret。
套餐用量对用户而言是如何运作的
用户会看到什么,以及你的帮助文档应该说明什么:
- 合格的请求会计入套餐用量。 它们消耗用户 Plus 或 Pro 套餐中的 ChatGPT Work 和 Codex 用量。
- 每个应用都有每周上限。 用户按整体每周用量的百分比来设置(文档中的设置示例从 10% 到 100%)。它是上限,不是预留额度池,因此在别处的大量使用可能先耗尽套餐。
- 使用 credits 需要主动开启。 达到限制后继续使用 credits 默认关闭,且要求该应用的上限设为 100%。
- Plus 有一个共享的五小时限制。 根据 账号与会话页面,它横跨所有使用该套餐的应用。Pro 不受此限制。
- 断开连接会停止后续使用。 它不会回退已经消耗的用量,OpenAI 也不会通知你的应用;你要等某个请求或刷新失败时才会发现。
用户可以在 ChatGPT 的 Settings、Usage(chatgpt.com/settings/usage)中管理这些设置,OpenAI 的 UI 指南 要求你用 Manage usage 链接到那里。
发布时有哪些参与者,以及如何获得 client ID
OpenAI 的 DevDay 回顾 列出了 16 个套餐用量合作伙伴,包括 Cognition 的 Devin、Notion、Vercel、T3、OpenClaw 和 Dactyl。The New Stack 还列出了 Amp、Warp、Kilo Code 和 OpenCode 等,其中 Lovable 标注为即将推出。如果你在做 OpenClaw,它在两份名单上都有。
据 The New Stack 报道,Sam Altman 在台上这样宣传:“现在你不必再为他们的 token 成本买单,就能让他们用起来。”
如何接入取决于你发布的是什么:
- 商业或托管应用: 登录功能属于有限试用。你需要申请 client ID,即通过 OpenAI 的意向表单加入等待名单,无论你只需要身份认证还是也要套餐用量(文档的 URL 把套餐用量称为 token sharing)。
- 开源和本地托管的工具: 套餐用量通过上面的自助流程向所有开源合作伙伴开放。
你的 API 账单会有哪些变化
现在你按 token 付费,并通过自己的定价收回成本。套餐用量把模型成本转移到用户的订阅上,因此你的利润不再取决于他们使用 AI 的强度。代价则是控制权。
| 你的 API key | 用户的 ChatGPT 套餐 | |
|---|---|---|
| 谁付费 | 你,按 token 计费 | 用户的套餐(只有他们主动开启才使用 credits) |
| 谁可以使用 | 所有用户 | 已授予 chatgpt.tokens.use.direct |
| 限制 | 你的速率限制档位 | 每周套餐用量、按应用的上限、Plus 的五小时窗口 |
| 请求形态 | 完整的 Responses API | store: false 和 stream: true 是必需的;不支持 temperature、max_output_tokens、file search 或 Code Interpreter |
| 典型失败 | 超出你的档位时返回 429 | 429 subscription_sharing_usage_limit_exceeded,或在流式响应中途出现相同 code 的 response.failed |
| 回退方案 | 由你自己设计 | 没有自动回退:OpenAI 不会自动切换计费 |
| 需要展示什么 | 你自己的用量和定价 | “正在使用 ChatGPT 套餐”、Manage usage 链接,以及你的哪些套餐支持它 |
这些限制来自 预览限制页面:需要存储对话状态或托管工具的功能,目前无法在用户的套餐上运行。
合理的默认做法是混合使用:Plus 和 Pro 用户的交互式工作使用套餐用量,其他用户以及后台任务、CI 和定时 agent 使用你自己的 key。触发上限时,展示 Manage usage,并把你自己提供的 credits 作为次要选项。API key vs OAuth 对比介绍了总体权衡,OAuth for AI agents 则介绍如何安全地代表用户行事。
如何在 Apifox 中测试登录流程及其失败路径
Apifox 并不负责用 ChatGPT 登录,它用来验证你的 OAuth 配置、token 调用和错误处理。然后在 Apifox 中创建一个环境。
1. 把客户端信息存为变量。 添加 SIWC_CLIENT_ID、SIWC_REDIRECT_URI,如果是机密客户端再添加 SIWC_CLIENT_SECRET 并设为敏感值;另外添加 ACCESS_TOKEN 用于套餐用量。以 {{SIWC_CLIENT_ID}} 的形式引用它们,这样保存的请求里就不会存有密钥。
2. 运行 Authorization Code 流程。 在 Auth 标签页中选择 OAuth 2.0 with Authorization Code with PKCE,填入上面的接口地址,把 scope 设为 openid profile email,并使用为你的客户端注册的回调 URL。Apifox OAuth 2.0 指南会逐一讲解每个字段。
3. 对你拿到的 ID token 做断言。 把换取 token 的请求单独保存为发送到 token 接口的 POST(code、verifier、redirect URI、client ID),并为它添加一个后置操作。签名和 nonce 的校验仍然应该放在你的后端。
const body = pm.response.json();
pm.test("token exchange returned an ID token", () => {
pm.expect(pm.response.code).to.eql(200);
pm.expect(body.id_token).to.be.a("string");
});
const decode = require("atob");
const part = body.id_token.split(".")[1].replace(/-/g, "+").replace(/_/g, "/");
const claims = JSON.parse(decode(part + "=".repeat((4 - (part.length % 4)) % 4)));
pm.test("ID token claims match this client", () => {
pm.expect(claims.iss).to.eql("https://auth.openai.com");
pm.expect(claims.aud).to.include(pm.environment.get("SIWC_CLIENT_ID"));
pm.expect(claims.sub).to.be.a("string").and.not.empty;
pm.expect(claims.exp * 1000).to.be.above(Date.now());
});
记录 name、email 和 picture,而不要对它们做断言,因为这些字段仅在可用时才返回。对于套餐用量,要断言 body.scope 包含 chatgpt.tokens.use.direct。
4. mock 这些失败路径。 真实的 Plus 账号并不适合拿来做测试夹具,因此可以从 Apifox mock 服务返回以下响应:
- 用户拒绝套餐用量: token 响应的
scope不包含chatgpt.tokens.use.direct。你的应用应保留登录状态,并提示启用套餐用量或改用其他计费方式。 - 达到上限: 429,其中
error.codesubscription_sharing_usage_limit_exceeded,以及在response.failed流事件中出现相同 code。断言你的应用会暂停套餐请求。 - 不符合资格: 403
subscription_sharing_user_not_eligible。不要重试,也不要反复走 OAuth 流程。 - 已断开连接: 刷新时返回
invalid_grant,或返回 401subscription_sharing_invalid_user。清除 token 并重新要求登录。
把这些用例串成一个测试场景,并用 Apifox CLI 在 CI 中运行。错误与恢复页面 列出了完整的错误集合。
5. 检查真实调用。 用一个真实的套餐 token,发送文档中的流式请求(在 Apifox 中即 Bearer {{ACCESS_TOKEN}}),并确认流以 response.completed 结束——这是唯一的成功信号:
curl --no-buffer https://api.openai.com/v1/responses \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6.1-sol",
"input": [{"role": "user", "content": "Say exactly: Hello, world!"}],
"store": false,
"stream": true
}'
常见问题
Free 用户可以使用 Sign in with ChatGPT 吗? 登录面向全球 ChatGPT 用户开放。要在其他应用中使用套餐,则需要 Plus 或 Pro。
我的应用会拿到用户的 OpenAI API key 吗? 不会。你获得的是 ID token,以及在启用套餐用量时用于合格的 Responses API 请求的 OAuth access token。
用户达到上限时会发生什么? 请求会失败并返回 subscription_sharing_usage_limit_exceeded:HTTP 429,或流式传输开始之后的 response.failed 事件。应暂停请求并链接到 Manage usage。
Plus 用户能通过合作方应用运行 GPT-6.1 Sol 吗? 文档中的示例使用 gpt-6.1-sol 搭配套餐 token,但在提供选项之前,先用该 token 列出账号可用的模型。更多内容见 GPT-6.1 Sol free。
下一步
如果你运营的是商业应用,现在就去加入等待名单,并在等待期间基于 mock 构建好上限和断开连接的处理逻辑。把套餐用量视为自有 API 计费之外的选项,而不是替代方案。把 token 断言和失败场景保存在 Apifox 中,这样等到你的 client ID 发下来时,唯一需要更换的变量就是真实的 token。
HiFox:将 Agent 变成真正的队友
另外,我们也在思考,AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台:你可以像给同事分派任务一样指派 Agent,在任务看板中跟踪进度、查看结果,让 Agent 成为团队里的队友。
👉 立即体验 HiFox:https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码,或者正在研究 Cursor、Claude Code 这些工具,
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流,还有各种新工具和新玩法。