320 VIEWS
Pinterest LinkedIn LINE

（編輯中：上次更新時間：2026年10月02日 12:39 JST）OpenAI 於9月29日在 DevDay 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
  • 一貫 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，《回顧2026年開發者日》
  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 – 概述