320 VISUALIZZAZIONI
Pinterest LinkedIn LINE

(Modifica in corso: ultimo aggiornamento 2026-10-02 12:39 JST) OpenAI annunciato al DevDay 2026 il 29 settembreAccedi con ChatGPT (SIWC) L'abbiamo annunciato ufficialmente. Vorrei verificarlo personalmente e scriverci un articolo, ma al momento non ho tempo. Quindi, pubblico qui sotto la bozza redatta da ChatGPT. Se trovate degli errori, fatemelo sapere su X.

SIWC è stato lanciato da OpenAI. Funzionalità del provider OpenID Connect / server di autorizzazione OAuthTuttavia, in realtà, le seguenti due funzionalità sono raggruppate sotto lo stesso marchio:

  1. Accesso tramite identità
    Utilizzando un account ChatGPT, un quasi standard Codice di autorizzazione OpenID Connect + PKCE.
  2. Difficoltà di pianificazione di ChatGPT
    Il limite di utilizzo incluso nei contratti ChatGPT, come Plus/Pro, può essere utilizzato da applicazioni OSS/compatibili esterne. Un meccanismo per utilizzare l'API Responses esponendola a un token di accesso OAuth..

Quest'ultima è piuttosto particolare. Si tratta più che altro di un'estensione dell'accesso tramite ChatGPT,Identità dell'abbonato ChatGPT + diritto di inferenza delegata Si tratta di un meccanismo per trasmettere informazioni ad applicazioni esterne tramite OAuth. OpenAI stessa afferma esplicitamente che l'identità e l'utilizzo del piano sono autorizzazioni separate. 1

OpenAI ha iniziato a implementare la sua funzionalità Identity su alcuni siti/plugin partner il 23 settembre 2026 e ne ha annunciato ufficialmente l'implementazione, incluso l'utilizzo del piano ChatGPT, al DevDay 2026 il 29 settembre.

Accesso tramite identità

La parte relativa all'identità è sostanzialmente quella standard di OpenID Connect.

Il documento di OpenAI relativo alla scoperta della produzione è in realtà disponibile pubblicamente. 2.

I metadati principali sono i seguenti:

項目valore
Emittentehttps://auth.openai.com
Endpoint di autorizzazionehttps://auth.openai.com/api/accounts/authorize
Endpoint tokenhttps://auth.openai.com/api/accounts/oauth/token
Endpoint UserInfohttps://auth.openai.com/api/accounts/oauth/userinfo
Punto finale di revocahttps://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
tipo_rispostacode solo
Grant_typeauthorization_code, refresh_token
PKCES256
tipo di soggettopublic
Firma del token IDRS256
autenticazione dell'endpoint del tokenclient_secret_basic, client_secret_post, none

In altre parole, la forma base è,

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

で す.

Quando si utilizza solo Identity su un sito web, la richiesta di autorizzazione è pressoché identica a una tipica richiesta OIDC, come nell'esempio fornito da OpenAI.

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

L'ambito è

openid
profile
email

で す.

profile Quindi, nome/immagine ecc.,email Successivamente richiederemo un indirizzo email e una conferma di verifica dell'indirizzo email. email_verified Viene fornito un elenco di rivendicazioni OIDC standard, tra cui le seguenti.3

Verifica del token ID

La Relying Party (RP) verificherà l'ID Token utilizzando JWKS come di consueto.

OpenAI afferma esplicitamente:

iss
aud
exp
nonce
sub
signature

Ti stanno chiedendo di verificarlo.

aud è RP client_id,iss は

https://auth.openai.com

で す. 4

Riguardo alla chiave di identità in RP, OpenAI afferma:

issuer + client_id + sub

Consigliamo di conservarlo.

È inoltre importante,

Non collegare automaticamente gli account esistenti utilizzando solo l'indirizzo email.

Ecco il punto. La corrispondenza dell'indirizzo email non è considerata prova di proprietà dell'account. Questa è la scelta di progettazione corretta.

Il tipo di soggetto in Discovery è:

"subject_types_supported": ["public"]

(fonte) https://auth.openai.com/.well-known/openid-configuration

Pertanto, al momento non stiamo pubblicizzando coppie di soggetti.

La modalità "Identity-only" non utilizza token di accesso.

Si tratta di un design piuttosto interessante.

In un tipico SIWC di un sito web, OpenAI è supportato.

Per l'accesso basato esclusivamente sull'identità, l'artefatto richiesto è id_tokenNon richiedere un token di accesso OpenAI o un token di aggiornamento.

Ecco cos'è.5.

L'endpoint UserInfo è stato rilevato, ma l'esempio standard di login Web di SIWC non presuppone la presenza di UserInfo. Non ho ancora verificato, quindi non so cosa succeda se vi si accede con un token di accesso. Capisco la necessità di evitare di restituire un token di accesso nei casi di sola identità (ma deve essere restituito perché richiesto dalla RFC 6749). Penso che sarebbe meglio per il gruppo di lavoro OAuth creare un nuovo tipo di concessione. Tuttavia, al momento, sembra che venga restituito perché deve essere restituito (←questo deve essere confermato). Quindi, dove viene utilizzato il token di accesso? Lo spiegherò più avanti.

Cliente pubblico / Cliente riservato

Io li ho entrambi.

Cliente pubblico

L'autenticazione dell'endpoint del token è:

none

Quindi, useremo PKCE.

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

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

Cliente confidenziale

Tra gli esempi attualmente documentati figurano:

client_secret_basic

で す.

Inoltre, mantiene la riservatezza delle informazioni (PKCE) anche con un cliente riservato.6.

La scoperta stessa

client_secret_basic
client_secret_post
none

Questi tre metodi vengono pubblicizzati.7.

Utilizzo del piano ChatGPT: Utilizzo di modelli OpenAI con un abbonamento.

Ottenere un token di accesso per il piano ChatGPT: problemi

Ora, come accennato all'inizio, l'accesso con ChatGPT ha "Difficoltà di pianificazione di ChatGPTEsiste una funzionalità chiamata "OpenAI Responses API". Questa consente alle applicazioni esterne di delegare le autorizzazioni per chiamare l'OpenAI Responses API dal piano ChatGPT dell'utente tramite OAuth. In questo modo, l'applicazione esterna (client) può specificare un modello OpenAI ed eseguire diverse operazioni (come leggere il web utilizzando strumenti, leggere e scrivere file, elaborare dati e visualizzare i risultati).

Diagramma di flusso TD A["Applicazione"] B["API di risposta"] C["Modello"] D["Ricerca Web"] E["File"] F["Codice"] G["Computer"] H["Server MCP"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

Quindi,

API di risposta = Primitive di base dell'esecuzione dell'agente utilizzando modelli OpenAI

Sarebbe meglio comprenderlo in questo modo.

Ora, per eseguire questa delega, è necessario un token di accesso e, in SIWC, il client utilizza quanto segue nella richiesta di autenticazione:scopeLo si ottiene facendone richiesta.8.

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

Inoltre,

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

Anche questo deve essere incluso nella richiesta di autorizzazione e nella richiesta di token.

Questo è in forma RFC 8707 Indicatori di risorse per OAuth 2.0 9 Sì. RFC 8707 è resourceQuesto meccanismo consente di specificare il server delle risorse di destinazione utilizzando un URI assoluto.

Pertanto, concettualmente,

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

と な り ま す.

Token di accesso aud inoltre,

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

si tratta di10Questo non è un endpoint Userinfo.

Esempio di token di accesso

Il payload pubblicato da OpenAI è concettualmente strutturato come segue.

{
  "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
}

In altre parole, anche l'Access Token è un JWT.

La durata della vita è,

  • Token di accesso: 1 ore
  • Aggiorna token: 30 日
  • Rotazione del token di aggiornamento ad ogni aggiornamento
  • Il nuovo Refresh Token avrà nuovamente una durata di 30 giorni.

で す.

La documentazione attuale non utilizza vincoli del mittente come DPoP e l'API delle risposte utilizza il normale

Authorization: Bearer <ACCESS_TOKEN>

Lo invierò in questo modo.11.

Utilizzo di un abbonamento ChatGPT tramite l'API Responses

Ad esempio,

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

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

で す.

OpenAI sta attualmente fornendo informazioni sull'utilizzo del piano SIWC.

store: false
stream: true

È necessario. 12.

In altre parole, non si tratta semplicemente di sostituire una normale chiave API con un token OAuth.

Alcune funzionalità dell'API Responses sono inoltre limitate; ad esempio, nell'anteprima corrente,

  • background
  • persistere conversation
  • previous_response_id tramite HTTP
  • Hosting MCP/connettori
  • generazione di immagini
  • ricerca file
  • Interprete di codice
  • utilizzo nativo del computer

Questi servizi non sono disponibili.13

dunque Un abbonamento API convertito in OAuth.È anche leggermente diverso.

estensioni proprietarie SIWC

Quarto metodo di registrazione del cliente: dynamic_agent_client

Con OAuth standard, è possibile preregistrare il client oppure utilizzare l'endpoint di registrazione dinamica del client RFC 7591. Nel contesto di OpenID, oggigiorno è possibile utilizzare anche OpenID Federation.

Il flusso OSS di SIWC è diverso da entrambi.

Nella richiesta di autorizzazione iniziale,

client_id=dynamic_agent_client

Questo utilizza uno pseudo-client speciale.

Inoltre,

agent_name_hint
ext_agent_host_id

Aggiungilo.14

Domanda:

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

E la risposta è:

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

diventa,L'ID client ufficiale viene rilasciato qui.15In breve, è come effettuare la registrazione del cliente contemporaneamente alla richiesta di autorizzazione.

Successivamente, l'endpoint del token sarà

dynamic_agent_client

Piuttosto, questa nuova emissione

oaiapp_xxxxx

Lo invierò.

Questo è chiaramente diverso da RFC 7591 Dynamic Client Area.

RFC 7591 in genere afferma:

POST registration_endpoint
       ↓
client_id
client_secret...

で す.

Il flusso SIWC OSS è,

sequenceDiagram autonumber partecipante C come client/agente OSS partecipante B come browser partecipante AS come endpoint di autorizzazione OpenAI partecipante U come utente C->>C: Genera stato, nonce, code_verifier / code_challenge C->>B: Apri URL di autorizzazione B->>AS: GET /api/accounts/authorize client_id=client_agente_dinamico tipo_risposta=codice redirect_uri=http://127.0.0.1:PORT/callback scope=openid profile email ... code_challenge=... code_challenge_method=S256 AS->>U: Autentica l'utente U-->>AS: Autenticazione completata AS->>U: Mostra il consenso / la registrazione dell'applicazione U-->>AS: Approva Nota su AS: Crea/registra un client concreto e emetti client_id = oaiapp_... AS-->>B: Reindirizzamento HTTP a redirect_uri ?code=AUTH_CODE &stato=STATO &client_id=oaiapp_... B-->>C: GET /callback client=CODICE_AUTORIZZAZIONE stato=STATO client_id=oaiapp_... Nota su C: Archivia oaiapp_... client_id Utilizzalo per la richiesta del token. non dynamic_agent_client

で す.

pertanto,

registrazione dinamica mediata dall'utente incorporata in una richiesta di autorizzazione

Questa è l'interpretazione corretta.

RFC 7591Sarebbe meglio non chiamarla Registrazione Client Dinamica compatibile.

ext_agent_host_id

Anche questa è un'interessante estensione di OpenAI.

Oltre al client OSS,

agent host

Esiste un concetto chiamato così.

Ad esempio,

Diagramma di flusso TD A["Registrazione client SIWC"] B["client_id"] A --> B B --> C["Laptop"] B --> D["VM"] C --> E["ext_agent_host_id A"] D --> F["ext_agent_host_id B"]

Questo è il modello.16.

Attualmente OpenAI utilizza gli ID host.

Raccomandazione

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

RFC 9278 JWK Thumbprint URI

anziché

urn:uuid:<uuid>

または

did:key:...

Lo riconoscono.17

Tuttavia, ciò che è estremamente importante a questo punto è:

OpenAI non verifica il possesso della chiave privata nemmeno utilizzando l'impronta digitale JWK.

Ecco il punto.18

pertanto,

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

で す.

Attualmente, si tratta semplicemente di un identificatore host stabile.

Essendo un'app nativa, si attiene in modo piuttosto rigoroso allo standard RFC 8252.

Nel desktop/client OSS,

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

È usato.

localhost Non utilizzare il letterale IP 127.0.0.1 Si tratta di una richiesta. Solo il numero di porta può essere modificato per ogni accesso.19.

Ciò è coerente con il reindirizzamento dell'interfaccia di loopback descritto nella RFC 8252.RFC 8252Lui stesso,

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

Ciò definisce e richiede l'uso di PKCE nelle app native.

Restituire l'accesso e id_token_hint

Una volta effettuata la registrazione, dalla prossima volta in poi,

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

Puoi usarlo.

È interessante notare che OpenAI in precedenza Anche se il token ID è scaduto... id_token_hint Può essere utilizzato comeÈ affermato chiaramente.20.

こ れ はOpenID Connect Core 1.0Non è che sia fuori dall'ambito.

Il nucleo OIDC stesso,

id_token_hint Questo è un suggerimento che indica la sessione autenticata corrente o passata.

E se è stato emesso dall'OP,exp Si consiglia di accettare le sessioni recenti anche se il limite di tempo è scaduto.

Pertanto, questa parte rappresenta un'implementazione OIDC piuttosto tipica.

Sono presenti alcune incongruenze nei metadati di Discovery.

Dal punto di vista della standardizzazione, questo è attualmente l'ambito che desta maggiore preoccupazione.

Documento di scoperta:

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

il,

resource.invoke
chatgpt.tokens.use.direct

Non c'è OpenAI

Tuttavia, la documentazione ufficiale della SIWC afferma chiaramente:

offline_access
resource.invoke
chatgpt.tokens.use.direct

Stiamo chiedendo21.

Questo non è necessariamente un difetto fatale in termini di specifiche,

La capacità di utilizzo del piano SIWC non può essere rilevata esclusivamente dai metadati di Discovery.

Pertanto, sarebbe meglio aggiungerlo.

Allo stesso modo,

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

Lo stiamo utilizzando secondo le modalità descritte nella RFC 8707, ma non sono presenti metadati specifici per SIWC relativi alla capacità di individuazione dell'utilizzo del piano.

Pertanto, la situazione attuale è,

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

Devi leggerli entrambi.

Nel caso del plugin ChatGPT, l'autenticazione OAuth viene duplicata.

L'integrazione con il plugin ChatGPT presenta una struttura ancora più interessante.

Secondo la spiegazione di OpenAI,

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

si tratta di22.

Transazione esterna

ChatGPT → Plugin:

/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

Transazione esterna

Plugin → OpenAI:

openid profile email

SIWC di

Il plugin verifica il token ID OpenAI per identificare l'account locale e quindi riavvia Outer OAuth.23.

pertanto,

SIWC non sostituisce il server di autorizzazione OAuth del plugin stesso.

Questo è importante.

Sarà incluso come livello interno della Federazione delle Identità.

Identità e autorizzazione sono intenzionalmente separate.

In sintesi:

diagramma di flusso TD A["account OpenAI / ChatGPT"] A -->|"Autenticazione OIDC email del profilo openid"| B["Applicazione"] B -->|"Sessione propria dell'applicazione"| C["Sessione locale"] B -->|"Autorizzazione facoltativa chatgpt.tokens.use.direct resource.invoke"| D["Token di accesso OAuth"] D -->|"Token Bearer"| E["API di risposte OpenAI"]

La sola autenticazione tramite identità non è sufficiente.

  • Conversazioni ChatGPT
  • memoria
  • file
  • dati di fatturazione
  • Chiave API

Queste cose non saranno oltrepassate. Centro assistenza OpenAI

ま た chatgpt.tokens.use.direct Senza di esso, non è possibile eseguire un'inferenza utilizzando un piano ChatGPT, anche se si è ottenuto un ID Token valido. Sviluppatori OpenAI

Questa separazione è piuttosto importante dal punto di vista della progettazione.

Dal punto di vista della sicurezza

Per riassumere il profilo attuale dal punto di vista della sicurezza OAuth/OIDC,

項目SIWC
codice di autorizzazione○
PKCE S256○ / Essenzialemente richiesto
state○
OIDC nonce○
URI di reindirizzamento esatto○
Browser esterno dell'app nativa○
Reindirizzamento di loopback○
Video rinfrescante○
Stile RFC 8707 resource○
AT vincolato al mittenteNon trovato nei documenti
DPoPNon trovato nei documenti
mTLSNon trovato nei documenti
PARNon da un punto di vista pericoloso.
JARrequest supportato
a coppie subNessuno, solo pubblico
Registrazione dinamicaMetodo originale OpenAI

Inoltre, nell'uso della tecnologia,

"request_uri_parameter_supported": false,
"request_parameter_supported": false

Pertanto, al momento non utilizziamo metodi di tipo oggetto JAR/request. https://auth.openai.com/.well-known/openid-configuration Ciò è visibile nell'immagine.

Aspetti progettuali di particolare rilievo

Se dipendesse da me, dal punto di vista della standardizzazione, prenderei in considerazione in particolare i seguenti quattro punti.

① Separazione tra "Accesso" e "Autorizzazione all'IA"

Questo è un buon progetto.

authentication != authorization != subscription entitlement

Questo è relativamente chiaro.

② L'abbonamento a ChatGPT diventa accesso alle risorse OAuth

chatgpt.tokens.use.direct Questo non è semplicemente un ambito API, ma in realtà,

"Questo client potrebbe occupare lo slot di abbonamento per questo abbonato ChatGPT."

Questa è la delegazione.

Dai "dati utente/azione API" che l'OAuth tradizionale presupponeva,delega di diritto economico Il significato di "ambito" si è ampliato.

Questo è piuttosto interessante dal punto di vista dei pagamenti tramite agenti e dell'autorità delegata.

③ La registrazione del cliente è vincolata all'utente

Emesso nel flusso OSS client_id ma,

user + selected workspace

È vincolato a24

Questo è convenzionale

client_id = software application/deployment

Questo è piuttosto diverso dal modello OAuth.

piuttosto,

client_id ≈ user-authorized agent registration

で す.

④ Aggiungere l'identità host a OAuth.

Inoltre,

client
user
workspace
host

Li trattiamo separatamente.

Questo diventerà importante nell'IA degli agenti in futuro.

Principal
Agent
Client
Runtime
Device/Host

Questa struttura è piuttosto simile alla separazione delle identità.

D'altra parte, ci sono alcuni punti che mi preoccupano.

Questa è la parte rilevante della progettazione del protocollo.

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

Tuttavia, attualmente,

ext_agent_host_id

Sebbene esista, il possesso della chiave privata dell'host non viene verificato.

Pertanto, l'identificazione host corrente è,

identification

E,

cryptographic binding

non è25.

Inoltre, il token di accesso è al portatore.

Se si riferisce a un lavoro di alto valore, allora in futuro,

JKT / DPoP / attested key

Penso che ci sia molto spazio per il binding in posti come questo. Si tratta fondamentalmente di un'implementazione FAPI.

ま と め

Accedere a ChatGPT è piuttosto semplice per un utente OIDC.

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

Inoltre, il profilo unico di OpenAI è il seguente:

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

Aggiungere,

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

Ce ne stiamo rendendo conto.

Ciò che è particolarmente importante è che non si tratta semplicemente di una "versione ChatGPT di Accedi con Google".Provider di identità + autorizzazione dei diritti di abbonato + sistema di registrazione agente/cliente/host Questa è la combinazione.

In termini di standardizzazione,RFC 8707 / RFC 8252 Pur dipendendo fortemente da OpenID Connect Core, dispone di estensioni personalizzate solo per la registrazione dinamica dei client e il binding agente-host.Organizzandolo in questo modo, risulta più facile da capire.

Fiocco di neve

  1. OpenAI, uno sguardo al DevDay 2026
  2. Documento di scoperta OpenAI OIDC
  3. Sviluppatori OpenAI
  4. Sviluppatori OpenAI: sul tuo sito web
  5. Per l'accesso standard basato solo sull'identità, l'artefatto richiesto è id_token. Non sono richiesti access_token o refresh_token di OpenAI; non fanno parte del contratto client standard basato solo sull'identità. Fonte: Sviluppatori OpenAI
  6. Sviluppatori OpenAI – Accedi con ChatGPT – Sul tuo sito web
  7. OpenAI
  8. Sviluppatori OpenAI: Registrazioni e accesso
  9. RFC 8707: Indicatori di risorse per OAuth 2.0 | Editor RFC
  10. Sviluppatori OpenAI
  11. Sviluppatori OpenAI – Accesso con ChatGPT – Modelli e inferenza
  12. Sviluppatori OpenAI – Accesso con ChatGPT – Modelli e inferenza
  13. Sviluppatori OpenAI – Accedi con ChatGPT – Limitazioni dell'anteprima
  14. Sviluppatori OpenAI: Registrazione e accesso
  15. Sviluppatori OpenAI – Accedi con ChatGPT – Registrazione e accesso
  16. OpenAI Developers - Accedi con ChatGPT - Panoramica
  17. Sviluppatori OpenAI
  18. Sviluppatori OpenAI – Accedi con ChatGPT – Panoramica
  19. Sviluppatori OpenAI – Accesso con ChatGPT – Registrazione e accesso
  20. Registrazione e accesso per gli sviluppatori OpenAI-SIWC
  21. Sviluppatori OpenAI – Accesso con ChatGPT – Registrazione e accesso
  22. Sviluppatori OpenAI – Nel tuo plugin ChatGPT
  23. Sviluppatori OpenAI – Accedi con ChatGPT – Nel tuo plugin ChatGPT
  24. Sviluppatori OpenAI – Accesso con ChatGPT – Panoramica
  25. Sviluppatori OpenAI: SIWC – Panoramica