320 景观
Pinterest LinkedIn LINE

（编辑中：上次更新时间：2026年10月02日 12:39 JST）OpenAI 于9月29日在2026年开发者大会上宣布了这一消息。使用 ChatGPT (SIWC) 登录 我们已经正式发布了。我很想亲自核实一下并写篇文章，但我现在没时间。所以，我把 ChatGPT 自己整理的草稿贴在下面。如果您发现任何错误，请在 X 上告诉我。

SIWC 由 OpenAI 发起。 OpenID Connect 提供程序/OAuth 授权服务器功能然而，实际上，以下两个功能属于同一品牌：

  1. 身份登录
    使用 ChatGPT 帐户，几乎是标准的 OpenID Connect 授权码 + PKCE。
  2. ChatGPT 规划困难
    ChatGPT 合约（如 Plus/Pro）中包含的使用限制可以通过外部 OSS/兼容应用程序使用。 一种通过将响应 API 暴露给 OAuth 访问令牌来使用响应 API 的机制。。

后者则非常独特。这更像是“使用 ChatGPT 登录”的延伸。ChatGPT 用户身份 + 委托推理权限 这是使用 OAuth 将信息传递给外部应用程序的机制。OpenAI 本身明确指出，身份和套餐使用是不同的权限。 1

OpenAI 于 2026 年 9 月 23 日开始向一些合作伙伴网站/插件推出其身份功能，并于 9 月 29 日在 DevDay 2026 上正式宣布了其实现，包括 ChatGPT 计划的使用。

身份登录

身份验证部分基本就是标准的 OpenID Connect。

OpenAI 的产品发现文档实际上是公开的。 2。

主要元数据如下：

项目値
发行者https://auth.openai.com
授权端点https://auth.openai.com/api/accounts/authorize
令牌端点https://auth.openai.com/api/accounts/oauth/token
用户信息端点https://auth.openai.com/api/accounts/oauth/userinfo
撤销端点https://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
响应类型code 只有
授权类型authorization_code, refresh_token
PKCES256
主题类型public
ID令牌签名RS256
令牌端点认证client_secret_basic, client_secret_post, none

换句话说，基本形式是：

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

。

当网站上仅使用身份验证时，授权请求几乎与 OpenAI 示例中的典型 OIDC 完全相同。

GET https://auth.openai.com/api/accounts/authorize?
    client_id=oaiapp_...
    &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
    &response_type=code
    &scope=openid%20profile%20email
    &state=...
    &nonce=...
    &code_challenge=...
    &code_challenge_method=S256

范围是

openid
profile
email

。

profile 所以，姓名/照片等等，email 然后我们会要求提供电子邮件地址和电子邮件验证声明。 email_verified 提供一份标准 OIDC 索赔清单，其中包括以下内容。3

ID令牌验证

依赖方（RP）将像往常一样使用 JWKS 验证 ID 令牌。

OpenAI明确指出，

iss
aud
exp
nonce
sub
signature

他们要求你核实此事。

aud 是RP client_id，iss は

https://auth.openai.com

。 4

关于RP中的身份密钥，OpenAI指出：

issuer + client_id + sub

我们建议保留它。

同样重要的是，

不要仅使用电子邮件地址自动关联现有帐户。

关键就在这里。邮箱匹配并不代表账户所有权。这样的设计是正确的。

Discovery 中的主题类型是：

"subject_types_supported": ["public"]

（来源） https://auth.openai.com/.well-known/openid-configuration

因此，我们目前不宣传成对主题。

仅身份验证不使用访问令牌。

这是一个相当有趣的设计。

在典型的网站 SIWC 中，OpenAI 是受支持的。

对于仅需身份验证的登录，所需的工件是 id_token请勿申请 OpenAI 访问令牌或刷新令牌。

就是这样。5。

UserInfo 端点已被发现，但标准的 SIWC Web 登录示例并未假定 UserInfo 的存在。我尚未进行验证，因此不清楚使用访问令牌访问该端点会发生什么情况。我理解在仅身份验证的情况下需要避免返回访问令牌（但由于 RFC 6749 的要求，必须返回）。我认为 OAuth 工作组最好创建一个新的授权类型。然而，目前看来，它之所以被返回，是因为必须返回（←这一点需要确认）。那么，访问令牌究竟用于何处呢？稍后我会解释。

公共客户/保密客户

我两个都有。

公共客户端

令牌端点身份验证是：

none

所以，我们将使用 PKCE。

POST /api/accounts/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=...
&redirect_uri=...
&client_id=...
&code_verifier=...

保密客户

目前已记录的示例包括：

client_secret_basic

。

此外，即使是机密客户，它也能保持 PKCE（个人身份和通信安全）。6。

发现本身

client_secret_basic
client_secret_post
none

这三种方法都有广告宣传。7。

ChatGPT 计划使用情况：使用订阅的 OpenAI 模型。

获取 ChatGPT 计划的访问令牌时遇到问题

如前所述，使用 ChatGPT 登录具有“ChatGPT 规划困难有一个名为“OpenAI Responses API”的功能。它允许外部应用程序通过 OAuth 授权，从用户的 ChatGPT 套餐中调用 OpenAI Responses API。利用此功能，外部应用程序（客户端）可以指定一个 OpenAI 模型并执行各种操作（例如使用工具读取网络、读写文件、进行思考并输出结果）。

流程图 TD A["应用程序"] B["响应 API"] C["模型"] D["网络搜索"] E["文件"] F["代码"] G["计算机"] H["MCP 服务器"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

所以，

响应 API = 使用 OpenAI 模型执行代理的基本原语

最好这样理解。

现在，为了执行此委托，需要一个访问令牌，在 SIWC 中，客户端在身份验证请求中使用以下内容：scope你可以通过申请获得它。8。

openid
profile
email
offline_access
resource.invoke
chatgpt.tokens.use.direct

此外，

resource=https://api.openai.com/v1

这还必须包含在授权请求和令牌请求中。

就形式而言 RFC 8707 OAuth 2.0 资源指示器 9 是的。RFC 8707 是 resource此机制允许您使用绝对 URI 指定目标资源服务器。

因此，从概念上讲，

           OpenAI Authorization Server
             auth.openai.com
                    │
                    │ Access Token
                    ▼
              External OSS app
                    │
                    │ Bearer AT
                    ▼
          OpenAI Resource Server
          api.openai.com/v1

进行对待。

访问令牌 aud 也

"aud": "https://api.openai.com/v1"

です10这不是用户信息端点。

访问令牌示例

OpenAI 发布的有效载荷在概念上结构如下。

{
  "sub": "...",
  "aud": "https://api.openai.com/v1",
  "client_id": "oaiapp_...",
  "scope":
    "chatgpt.tokens.use.direct email offline_access openid profile resource.invoke",

  "https://api.openai.com/auth": {
    "per_user_salt": "...",
    "encrypted_auth_metadata": "..."
  },

  "iss": "https://auth.openai.com",
  "iat": 1790032532,
  "exp": 1790036132,
  "jti": "...",
  "nbf": 1790032532
}

换句话说，访问令牌也是一个 JWT。

寿命是，

  • 访问令牌： 1小时
  • 刷新令牌： 30日期
  • 每次刷新时轮换刷新令牌
  • 新的刷新令牌的有效期仍为 30 天。

。

当前文档未使用 DPoP 等发件人约束机制，响应 API 使用的是常规机制。

Authorization: Bearer <ACCESS_TOKEN>

我会按原样发送。11。

使用响应 API 消费 ChatGPT 订阅

例如，

POST https://api.openai.com/v1/responses
Authorization: Bearer <SIWC_ACCESS_TOKEN>
Content-Type: application/json

{
  "model": "...",
  "input": [...],
  "store": false,
  "stream": true
}

。

OpenAI 目前正在提供有关 SIWC 计划使用情况的信息。

store: false
stream: true

这是必须的。 12。

换句话说，这不仅仅是将普通的 API 密钥替换为 OAuth 令牌的问题。

响应 API 的某些功能也受到限制；例如，在当前的预览版中，

  • background
  • persistent conversation
  • previous_response_id 通过 HTTP
  • 托管 MCP/连接器
  • 图像生成
  • 文件搜索
  • 代码解释器
  • 本地计算机使用

这些服务不可用。13

所以 使用 OAuth 实现的 API 订阅。它也略有不同。

SIWC专有扩展

第四种客户端注册方法：dynamic_agent_client

使用标准 OAuth 时，您可以预先注册客户端，或者使用 RFC 7591 动态客户端注册端点。在 OpenID 的上下文中，如今使用 OpenID Federation 也是一种选择。

SIWC 的 OSS 流程与这两者都不同。

在初始授权请求中，

client_id=dynamic_agent_client

它使用了一种特殊的伪客户端。

此外，

agent_name_hint
ext_agent_host_id

添加它。14

例えば：

GET https://auth.openai.com/api/accounts/authorize?

 client_id=dynamic_agent_client
 &agent_name_hint=OpenClaw
 &ext_agent_host_id=urn:uuid:...
 &response_type=code
 &redirect_uri=http://127.0.0.1:1455/auth/callback

 &scope=openid profile email
        offline_access
        resource.invoke
        chatgpt.tokens.use.direct

 &resource=https://api.openai.com/v1

 &state=...
 &nonce=...
 &code_challenge=...
 &code_challenge_method=S256

回调函数是：

?code=...
&state=...
&client_id=oaiapp_xxxxx

接下来，官方客户端 ID 在此处发布。15简而言之，这就像在进行授权请求的同时执行客户端注册一样。

随后，令牌端点将

dynamic_agent_client

相反，这项新发行

oaiapp_xxxxx

我会寄出去。

这显然与 RFC 7591 动态客户端区域不同。

RFC 7591 通常规定：

POST registration_endpoint
       ↓
client_id
client_secret...

。

SIWC OSS流程是，

sequenceDiagram 自动编号参与者 C 作为 OSS 客户端/代理参与者 B 作为浏览器参与者 AS 作为 OpenAI 授权端点参与者 U 作为用户 C->>C：生成状态、随机数、 code_verifier / code_challenge C->>B: 打开授权 URL B->>AS: GET /api/accounts/authorize client_id=dynamic_agent_client response_type=代码redirect_uri=http://127.0.0.1:PORT/callback scope=openid 个人资料电子邮件 ...代码挑战=... code_challenge_method=S256 AS->>U：验证用户 U-->>AS：验证完成 AS->>U：显示同意/应用程序注册 U-->>AS：批准 AS 上的注释：创建/注册具体客户端并发出 client_id = oaiapp_... AS-->>B: HTTP 重定向到 redirect_uri ?code=AUTH_CODE &state=州&client_id=oaiapp_... B-->>C: GET /callback client=AUTH_CODE状态=STATE client_id=oaiapp_... 注意：C 端已发布 oaiapp_... client_id将其用于令牌请求。不是 dynamic_agent_client

。

因此，

嵌入到授权请求中的用户介导动态注册

这是正确的解释。

RFC 7591最好不要称之为兼容的动态客户端注册。

ext_agent_host_id

这也是一个很有意思的OpenAI扩展。

除了开源软件客户端之外，

agent host

有一个概念就叫这个。

例如，

流程图 TD A["一个 SIWC 客户端注册"] B["客户端 ID"] A --> B B --> C["笔记本电脑"] B --> D["虚拟机"] C --> E["外部代理主机 ID A"] D --> F["外部代理主机 ID B"]

这是模型。16。

OpenAI目前使用主机ID。

推荐

urn:ietf:params:oauth:jwk-thumbprint:...

RFC 9278 JWK 指纹 URI

而不是

urn:uuid:<uuid>

或者

did:key:...

他们承认这一点。17

然而，此时此刻最为重要的是：

即使使用 JWK 指纹，OpenAI 也不会验证私钥的持有情况。

这就是关键所在。18

因此，

JWK thumbprint host ID
 ≠ proof-of-possession
 ≠ DPoP
 ≠ client authentication

。

目前，它只是一个稳定的主机标识符。

作为一款原生应用，它与 RFC 8252 非常吻合。

在开源软件桌面/客户端中，

http://127.0.0.1:{port}/auth/callback

被使用。

localhost 不要使用 IP 字面值 127.0.0.1 这是一项请求。每次登录只能更改端口号。19。

这与 RFC 8252 中的环回接口重定向一致。RFC 8252他本人，

http://127.0.0.1:{port}/...

这规定并要求在原生应用程序中使用 PKCE。

返回登录和 id_token_hint

注册后，从下次开始，

client_id=<issued oaiapp_...>
ext_agent_host_id=...
id_token_hint=<previous ID Token>
login_hint=user@example.com

你可以用它。

有趣的是，OpenAI此前 即使 ID 令牌已过期…… id_token_hint 可用作这一点已明确说明。20。

これはOpenID Connect Core 1.0并非超出范围。

OIDC核心本身，

id_token_hint 这是指示当前或过去已验证会话的提示。

如果是楼主发布的，exp 即使时间限制已过，我们也建议接受最近的会话。

因此，这部分是一个相当典型的 OIDC 实现。

Discovery 元数据中存在一些不一致之处。

从标准化的角度来看，这是目前最令人关注的领域。

发现文件：

"scopes_supported": [
  "openid",
  "profile",
  "email",
  "offline_access"
]

则

resource.invoke
chatgpt.tokens.use.direct

没有 OpenAI

然而，SIWC的官方文件明确指出：

offline_access
resource.invoke
chatgpt.tokens.use.direct

我们正在请求21。

从规格方面来看，这未必是一个致命缺陷。

仅凭发现元数据无法发现 SIWC 计划使用情况功能。

因此，最好还是加上它。

同样的，

resource=https://api.openai.com/v1

我们正在按照 RFC 8707 的方式使用它，但是没有 SIWC 特定的计划使用能力发现元数据。

因此，目前的情况是：

OIDC discovery
   +
out-of-band OpenAI SIWC profile documentation

两本都需要阅读。

对于 ChatGPT 插件，OAuth 被重复使用了。

与 ChatGPT 插件的集成结构更加有趣。

根据 OpenAI 的解释，

ChatGPT
   │
   │ outer OAuth
   ▼
Plugin / external application
   │
   │ inner SIWC/OIDC
   ▼
OpenAI Authorization Server

です22。

外部交易

ChatGPT → 插件：

/oauth/authorize
  ?response_type=code
  &client_id=CHATGPT_CONNECTOR_CLIENT_ID
  &redirect_uri=...
  &scope=...
  &state=...
  &code_challenge=...
  &code_challenge_method=S256
  &resource=...
  &login_hint=...
  &target_flow=chatgpt_siwc

内部交易

插件 → OpenAI：

openid profile email

SIWC

该插件验证 OpenAI ID 令牌以识别本地帐户，然后重新启动外部 OAuth。23。

因此，

SIWC 不会取代插件自身的 OAuth 授权服务器。

这才是最重要的。

它将作为身份联盟的内层组成部分。

身份验证和授权有意分开。

总结起来：

流程图 TD A["OpenAI / ChatGPT 帐户"] A -->|"OIDC 身份验证" openid 配置文件电子邮件”| B["应用程序"] B -->|"应用程序自身的会话"| C["本地会话"] B -->|"可选授权chatgpt.tokens.use.direct resource.invoke”| D["OAuth 访问令牌"] D -->|"持有者令牌"| E["OpenAI 响应 API"]

仅凭身份登录是不够的。

  • ChatGPT对话
  • 记忆
  • 档
  • 计费数据
  • API密钥

这些地方禁止通行。 OpenAI 帮助中心

また chatgpt.tokens.use.direct 如果没有它，即使您已获得有效的 ID Token，您也无法使用 ChatGPT 计划执行推理。 OpenAI 开发者

从设计的角度来看，这种分离非常重要。

从安全角度来看

从 OAuth/OIDC 安全角度总结当前概况：

项目SIWC
授权码○
PKCE S256○ / 基本必需
state○
国际数据中心 nonce○
确切的重定向 URI○
原生应用外部浏览器○
回环重定向○
令人耳目一新的视频○
RFC 8707 风格 resource○
发送方受限的AT文档中未找到。
DPoP文档中未找到。
传输层安全协议文档中未找到。
PAR从危险的角度来看，并非如此。
JARrequest 不支持
成对 sub无，仅限公开
动态注册OpenAI 原创方法

此外，在技术应用方面，

"request_uri_parameter_supported": false,
"request_parameter_supported": false

因此，我们目前不使用 JAR/request 对象类型的方法。 https://auth.openai.com/.well-known/openid-configuration 从图中可以看出这一点。

特别值得注意的设计要点

如果由我来决定，从标准化的角度来看，我会特别关注以下四点。

① 分离“登录”和“AI权限”

这是一个很好的设计。

authentication != authorization != subscription entitlement

这一点比较清楚。

② ChatGPT 订阅变为 OAuth 资源访问

chatgpt.tokens.use.direct 这不仅仅是 API 的作用域，实际上，

“此客户端可能会占用此 ChatGPT 订阅者的订阅名额。”

这就是代表团。

从传统 OAuth 所假定的“用户数据/API 操作”来看，经济权利委托 “范围”的含义已经扩大。

从代理支付和委托授权的角度来看，这很有意思。

③ 客户端注册由用户控制

以 OSS 流程发布 client_id 但是，

user + selected workspace

它必然如此24

这是惯例。

client_id = software application/deployment

这与 OAuth 模型截然不同。

相反，

client_id ≈ user-authorized agent registration

。

④ 将主机身份添加到 OAuth。

此外，

client
user
workspace
host

我们会分别处理它们。

这将在未来的智能体人工智能发展中变得至关重要。

Principal
Agent
Client
Runtime
Device/Host

这种结构与身份分离非常相似。

另一方面，有些问题令我担忧。

这是协议设计中相关的部分。

        User
         │
         │ owns
         ▼
 ChatGPT subscription
         │
         │ delegates entitlement
         ▼
       Client
         │
         │ runs on
         ▼
     Agent Host
         │
         │ Bearer AT
         ▼
 Responses Resource Server

然而，目前，

ext_agent_host_id

虽然主机私钥存在，但其持有情况无法得到验证。

因此，当前主机识别信息为：

identification

和，

cryptographic binding

不是25。

此外，访问令牌是 Bearer 类型的。

如果指的是高价值工作，那么在未来，

JKT / DPoP / attested key

我认为像这样的地方有很多绑定空间。它本质上就是FAPI的实现。

概括

对于 OIDC 来说，使用 ChatGPT 登录非常简单。

OIDC Authorization Code
+ PKCE S256
+ nonce
+ public sub
+ standard ID Token validation

此外，OpenAI 的独特之处在于：

dynamic_agent_client
agent_name_hint
ext_agent_host_id
resource.invoke
chatgpt.tokens.use.direct

添加，

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

を実现しています。

尤其重要的是，这并非仅仅是“ChatGPT 版的 Google 登录”。身份提供商 + 用户授权 + 代理/客户端/主机注册系统 这就是组合方式。

就标准化而言，RFC 8707 / RFC 8252 虽然它严重依赖 OpenID Connect Core，但它只有自己的自定义扩展，用于动态客户端注册和代理-主机绑定。这样组织起来更容易理解。

脚注

  1. OpenAI，《回顾20​​26年开发者日》
  2. OpenAI OIDC 发现文档
  3. OpenAI 开发者
  4. OpenAI开发者：在您的网站上
  5. 对于标准的仅身份验证登录，所需的工件是 id_token。不需要 OpenAI access_token 或 refresh_token；它们不属于标准的仅身份验证客户端协议的一部分。来源： OpenAI 开发者
  6. OpenAI开发者 – 使用ChatGPT登录 – 在您的网站上
  7. OpenAI
  8. OpenAI开发者：注册和登录
  9. RFC 8707：OAuth 2.0 的资源指示器 | RFC 编辑器
  10. OpenAI 开发者
  11. OpenAI开发者 – 使用ChatGPT登录 – 模型和推理
  12. OpenAI开发者 – 使用ChatGPT登录 – 模型和推理
  13. OpenAI 开发者 – 使用 ChatGPT 登录 – 预览限制
  14. OpenAI开发者：注册和登录
  15. OpenAI开发者 – 使用ChatGPT登录 – 注册和登录
  16. OpenAI开发者-使用ChatGPT登录-概述
  17. OpenAI 开发者
  18. OpenAI开发者 – 使用ChatGPT登录 – 概述
  19. OpenAI开发者 – 使用ChatGPT登录 – 注册和登录
  20. OpenAI开发者-SIWC-注册和登录
  21. OpenAI开发者 – 使用ChatGPT登录 – 注册和登录
  22. OpenAI 开发者 – 在您的 ChatGPT 插件中
  23. OpenAI 开发者 – 使用 ChatGPT 登录 – 在您的 ChatGPT 插件中
  24. OpenAI开发者 – 使用ChatGPT登录 – 概述
  25. OpenAI开发者：SIWC – 概述