323 VUES
Pinterest LinkedIn LINE

(Révision en cours : dernière mise à jour le 02/10/2026 à 12h39 JST) OpenAI a fait cette annonce lors du DevDay 2026 le 29 septembre.Se connecter avec ChatGPT (SIWC) Nous l'avons annoncé officiellement. J'aimerais le vérifier moi-même et écrire un article à ce sujet, mais je n'en ai pas le temps pour le moment. Je publie donc ci-dessous le brouillon rédigé par ChatGPT. Si vous trouvez des erreurs, merci de me le signaler sur X.

SIWC a été lancé par OpenAI. Fonctionnalité de fournisseur OpenID Connect / serveur d'autorisation OAuthCependant, en réalité, les deux fonctionnalités suivantes appartiennent à la même marque :

  1. Connexion d'identité
    En utilisant un compte ChatGPT, une méthode quasi standard Code d'autorisation OpenID Connect + PKCE.
  2. Difficultés de planification de ChatGPT
    La limite d'utilisation incluse dans les contrats ChatGPT tels que Plus/Pro peut être utilisée à partir d'applications externes OSS/compatibles. Un mécanisme permettant d'utiliser l'API Responses en l'exposant à un jeton d'accès OAuth..

Cette dernière option est assez particulière. Il s'agit plutôt d'une extension de la « connexion avec ChatGPT ».Identité de l'abonné ChatGPT + droit d'inférence déléguée Il s'agit d'un mécanisme permettant de transmettre des informations à des applications externes via OAuth. OpenAI précise d'ailleurs que l'identité et l'utilisation du forfait constituent des autorisations distinctes. 1

OpenAI a commencé à déployer sa fonctionnalité Identity sur certains sites/plugins partenaires le 23 septembre 2026 et a officiellement annoncé sa mise en œuvre, y compris l'utilisation du plan ChatGPT, lors du DevDay 2026 le 29 septembre.

Connexion d'identité

La partie relative à l'identité est assez standard OpenID Connect.

Le document de découverte de la production d'OpenAI est en fait accessible au public. 2.

Les principales métadonnées sont les suivantes :

éléments値
Emetteurhttps://auth.openai.com
Point de terminaison d'autorisationhttps://auth.openai.com/api/accounts/authorize
Point de terminaison du jetonhttps://auth.openai.com/api/accounts/oauth/token
Point de terminaison UserInfohttps://auth.openai.com/api/accounts/oauth/userinfo
Point de terminaison de révocationhttps://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
type_réponsecode の み
type_octroiauthorization_code, refresh_token
PCCES256
type de sujetpublic
Signature de jeton d'identificationRS256
authentification du point de terminaison de jetonclient_secret_basic, client_secret_post, none

Autrement dit, la forme de base est,

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

で す.

Lorsqu'on utilise uniquement l'identité sur un site web, la requête d'autorisation est presque identique à une requête OIDC classique dans l'exemple fourni par 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

La portée est

openid
profile
email

で す.

profile Donc, nom/photo, etc.email Nous vous demanderons ensuite un courriel et une demande de vérification de courriel. email_verified Une liste des revendications OIDC standard, comprenant les suivantes, est fournie.3

Vérification du jeton d'identification

La partie de confiance (RP) vérifiera le jeton d'identification en utilisant JWKS comme d'habitude.

OpenAI déclare explicitement,

iss
aud
exp
nonce
sub
signature

Ils vous demandent de vérifier cela.

aud est RP client_id,iss は

https://auth.openai.com

で す. 4

Concernant la clé d'identité dans RP, OpenAI déclare :

issuer + client_id + sub

Nous vous recommandons de le conserver.

Il est également important de noter que

Ne liez pas automatiquement les comptes existants en utilisant uniquement l'adresse e-mail.

C'est là le point essentiel. La correspondance des adresses e-mail ne constitue pas une preuve de propriété du compte. C'est un choix de conception judicieux.

Le type de sujet dans Discovery est :

"subject_types_supported": ["public"]

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

Par conséquent, nous ne faisons actuellement pas la promotion de sujets appariés.

L'authentification basée uniquement sur l'identité n'utilise pas de jetons d'accès.

C'est un design plutôt intéressant.

Dans la configuration SIWC typique d'un site web, OpenAI est pris en charge.

Pour une authentification basée uniquement sur l'identité, l'artefact requis est : id_tokenNe demandez pas de jeton d'accès ou de jeton d'actualisation OpenAI.

としています5.

Le point de terminaison UserInfo a été découvert, mais l'exemple standard de connexion Web SIWC ne présuppose pas sa présence. Je n'ai pas encore vérifié, donc j'ignore ce qui se passe si on y accède avec un jeton d'accès. Je comprends la nécessité d'éviter de renvoyer un jeton d'accès dans les cas d'authentification basée uniquement sur l'identité (mais il doit être renvoyé car la RFC 6749 l'exige). Je pense qu'il serait préférable que le groupe de travail OAuth crée un nouveau type d'autorisation. Cependant, actuellement, il semble qu'il soit renvoyé par obligation (← à confirmer). Alors, où est utilisé le jeton d'accès ? Je l'expliquerai plus tard.

Client public / Client confidentiel

J'ai les deux.

Client public

L'authentification par point de terminaison de jeton est :

none

Nous utiliserons donc 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 confidentiel

Les exemples actuellement documentés comprennent :

client_secret_basic

で す.

De plus, il maintient le protocole PKCE même avec un client confidentiel.6.

La découverte elle-même

client_secret_basic
client_secret_post
none

Ces trois méthodes sont annoncées.7.

Utilisation du forfait ChatGPT : Utilisation des modèles OpenAI avec un abonnement.

Problème d'obtention d'un jeton d'accès pour le forfait ChatGPT

Comme mentionné au début, la connexion avec ChatGPT a «Difficultés de planification de ChatGPTIl existe une fonctionnalité appelée « API de réponses OpenAI ». Celle-ci permet aux applications externes de déléguer l'autorisation d'appeler l'API de réponses OpenAI depuis le compte ChatGPT de l'utilisateur via OAuth. Grâce à cela, l'application externe (client) peut spécifier un modèle OpenAI et effectuer diverses opérations (telles que la lecture du Web à l'aide d'outils, la lecture et l'écriture de fichiers, le traitement et l'affichage des résultats).

Diagramme de flux TD A["Application"] B["API de réponses"] C["Modèle"] D["Recherche Web"] E["Fichiers"] F["Code"] G["Ordinateur"] H["Serveur MCP"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

Donc

API de réponses = Primitives de base de l'exécution d'agents utilisant des modèles OpenAI

Il serait préférable de le comprendre ainsi.

Pour effectuer cette délégation, un jeton d'accès est requis, et dans SIWC, le client utilise les éléments suivants dans la requête d'authentification :scopeVous l'obtenez en le demandant.8.

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

En outre,

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

Cela doit également être inclus dans la demande d'autorisation et la demande de jeton.

En termes de forme RFC 8707 Indicateurs de ressources pour OAuth 2.0 9 Oui. La RFC 8707 est resourceCe mécanisme vous permet de spécifier le serveur de ressources cible à l'aide d'un URI absolu.

Par conséquent, conceptuellement,

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

と な り ま す.

Jeton d'accès aud Aussi

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

で す10Il ne s'agit pas d'un point de terminaison Userinfo.

Exemple de jeton d'accès

La charge utile publiée par OpenAI est conceptuellement structurée comme suit.

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

Autrement dit, le jeton d'accès est également un JWT.

La durée de vie est,

  • Jeton d'accès: 1 heure
  • Jeton d'actualisation : 30 date
  • Rotation du jeton de rafraîchissement à chaque rafraîchissement
  • Le nouveau jeton d'actualisation aura à nouveau une durée de vie de 30 jours.

で す.

La documentation actuelle n'utilise pas de mécanismes de restriction de l'expéditeur tels que DPoP, et l'API Responses utilise le mécanisme standard.

Authorization: Bearer <ACCESS_TOKEN>

Je l'enverrai tel quel.11.

Utilisation d'un abonnement ChatGPT avec l'API Responses

例 え ば,

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

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

で す.

OpenAI fournit actuellement des informations sur l'utilisation du plan SIWC.

store: false
stream: true

Ceci est requis. 12.

Autrement dit, il ne s'agit pas simplement de remplacer une clé API classique par un jeton OAuth.

Certaines fonctionnalités de l'API Responses sont également limitées ; par exemple, dans la version préliminaire actuelle,

  • background
  • persistant conversation
  • previous_response_id via HTTP
  • Hébergement MCP/connecteurs
  • génération d'image
  • recherche de fichier
  • Interprète de code
  • utilisation native de l'ordinateur

Ces services ne sont pas disponibles.13

Donc Un abonnement API mis en œuvre à l'aide d'OAuth.C'est aussi légèrement différent.

extensions propriétaires SIWC

Quatrième méthode d'enregistrement client : dynamic_agent_client

Avec OAuth standard, vous pouvez soit préenregistrer le client, soit utiliser le point de terminaison d'enregistrement dynamique du client (RFC 7591). Dans le contexte d'OpenID, l'utilisation de la fédération OpenID est également possible.

Le flux OSS de SIWC est différent des deux autres.

Dans la demande d'autorisation initiale,

client_id=dynamic_agent_client

Cela utilise un pseudo-client spécial.

さ ら に,

agent_name_hint
ext_agent_host_id

Ajoutez-le.14

Par exemple:

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

Et le rappel est,

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

と な り 、L'identifiant client officiel est délivré ici.15En résumé, c'est comme effectuer l'enregistrement du client en même temps que la demande d'autorisation.

Par la suite, le point de terminaison du jeton sera

dynamic_agent_client

Il s'agit plutôt de ce nouveau numéro d'émission.

oaiapp_xxxxx

Je vais l'envoyer.

Cela diffère clairement de la zone client dynamique RFC 7591.

La RFC 7591 stipule généralement :

POST registration_endpoint
       ↓
client_id
client_secret...

で す.

Le flux SIWC OSS est,

Diagramme de séquence numérotation automatique participant C en tant que client/agent OSS participant B en tant que navigateur participant AS en tant que point de terminaison d'autorisation OpenAI participant U en tant qu'utilisateur C->>C : Générer l'état, le nonce, code_verifier / code_challenge C->>B : Ouvrir l’URL d’autorisation B->>AS : GET /api/accounts/authorize client_id=client_agent_dynamique type_de_réponse=code redirect_uri=http://127.0.0.1:PORT/callback portée=courriel du profil openid ... code_challenge=... code_challenge_method=S256 AS->>U : Authentification de l’utilisateur U-->>AS : Authentification terminée AS->>U : Afficher le consentement / l’enregistrement de l’application U-->>AS : Approuver Remarque AS : Créer/enregistrer un client concret et émettre client_id = oaiapp_... AS-->>B : Redirection HTTP vers redirect_uri ?code=CODE_AUTH &état=ÉTAT &client_id=oaiapp_... B-->>C: GET /callback client=CODE_AUTH état=ÉTAT client_id=oaiapp_... Note concernant C : Magasin émis oaiapp_... client_id Utilisez-le pour la demande de jeton. pas de client d'agent dynamique

で す.

Donc,

inscription dynamique gérée par l'utilisateur et intégrée à une demande d'autorisation

C'est l'interprétation correcte.

RFC 7591Il serait préférable de ne pas l'appeler « enregistrement dynamique de client compatible ».

ext_agent_host_id

Il s'agit également d'une extension intéressante d'OpenAI.

En plus du client OSS,

agent host

Il existe un concept appelé cela.

例 え ば,

Diagramme de flux TD A["Enregistrement d'un client SIWC"] B["client_id"] A --> B B --> C["Ordinateur portable"] B --> D["VM"] C --> E["ext_agent_host_id A"] D --> F["ext_agent_host_id B"]

Voici le modèle.16.

OpenAI utilise actuellement des identifiants d'hôte.

Recommandation

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

URI d'empreinte numérique JWK RFC 9278

au lieu

urn:uuid:<uuid>

Ou

did:key:...

Ils le reconnaissent.17

Cependant, ce qui est extrêmement important à ce stade, c'est que

OpenAI ne vérifie pas la possession de la clé privée, même en utilisant l'empreinte JWK.

C'est bien là le problème.18

Donc,

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

で す.

Actuellement, il s'agit simplement d'un identifiant d'hôte stable.

En tant qu'application native, elle respecte de très près la RFC 8252.

Dans les applications de bureau/clients OSS,

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

を 使 い ま す.

localhost N'utilisez pas de littéral IP 127.0.0.1 Ceci est une requête. Seul le numéro de port peut être modifié à chaque connexion.19.

Ceci est conforme à la redirection d'interface de bouclage décrite dans la RFC 8252.RFC 8252Lui-même,

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

Ceci définit et exige l'utilisation de PKCE dans les applications natives.

Retour à la connexion et id_token_hint

Une fois inscrit, à partir de la prochaine fois,

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

Vous pouvez l'utiliser.

Il est intéressant de noter qu'OpenAI avait précédemment… Même si le jeton d'identification a expiré... id_token_hint Peut être utilisé commeC'est clairement indiqué.20.

こ れ はOpenID Connect Core 1.0Ce n'est pas que cela soit hors du champ d'application.

Le noyau OIDC lui-même,

id_token_hint Ceci est une indication de la session authentifiée actuelle ou passée.

Et si elle a été émise par OP,exp Nous vous recommandons d'accepter les sessions récentes même si le délai est dépassé.

Par conséquent, cette partie constitue une implémentation OIDC assez typique.

Il existe certaines incohérences dans les métadonnées de Discovery.

Du point de vue de la normalisation, c'est actuellement le domaine qui suscite le plus de préoccupations.

Document de découverte :

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

に は,

resource.invoke
chatgpt.tokens.use.direct

Il n'y a pas OpenAI

Cependant, la documentation officielle du SIWC indique clairement :

offline_access
resource.invoke
chatgpt.tokens.use.direct

Nous demandons21.

Il ne s'agit pas nécessairement d'un défaut fatal en termes de spécifications,

La capacité d'utilisation du plan SIWC ne peut pas être découverte à partir des seules métadonnées de découverte.

Il serait donc préférable de l'ajouter.

De même

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

Nous l'utilisons à la manière de la RFC 8707, mais il n'existe pas de métadonnées de découverte des capacités d'utilisation des plans spécifiques au SIWC.

Par conséquent, la situation actuelle est la suivante :

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

Vous devez lire les deux.

Dans le cas du plugin ChatGPT, OAuth est dupliqué.

L'intégration avec le plugin ChatGPT présente une structure encore plus intéressante.

Selon les explications d'OpenAI,

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

で す22.

Transaction externe

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

Transaction interne

Plugin → OpenAI :

openid profile email

SIWC par

Le plugin vérifie le jeton d'identification OpenAI pour identifier le compte local, puis redémarre l'authentification OAuth externe.23.

Donc,

SIWC ne remplace pas le serveur d'autorisation OAuth propre au plugin.

C'est important.

Elle sera intégrée comme couche interne de la Fédération d'identités.

L'identité et l'autorisation sont intentionnellement séparées.

En résumé :

Diagramme de flux TD A["Compte OpenAI / ChatGPT"] A -->|"Authentification OIDC" Adresse e-mail du profil OpenID | B["Application"] B -->|"Session propre à l'application" | C["Session locale"] B -->|"Autorisation facultative chatgpt.tokens.use.direct resource.invoke"| D["Jeton d'accès OAuth"] D -->|"Jeton porteur"| E["API de réponses OpenAI"]

La simple authentification par identité ne suffit pas.

  • Conversations ChatGPT
  • Mémoire
  • fichiers
  • données de facturation
  • Clé API

Ces lignes ne seront pas franchies. Centre d'aide OpenAI

ま た chatgpt.tokens.use.direct Sans cela, vous ne pouvez pas effectuer d'inférence à l'aide d'un plan ChatGPT, même si vous avez obtenu un jeton d'identification valide. Développeurs OpenAI

Cette séparation est assez importante du point de vue de la conception.

Du point de vue de la sécurité

Pour résumer le profil actuel du point de vue de la sécurité OAuth/OIDC,

élémentsSIWC
Code d'autorisation○
PKCE S256○ / Essentiellement requis
state○
OIDC nonce○
URI de redirection exacte○
application native navigateur externe○
Redirection de bouclage○
Vidéo rafraîchissante○
style RFC 8707 resource○
AT à expéditeur limitéIntrouvable dans les documents
DPoPIntrouvable dans les documents
mTLSIntrouvable dans les documents
PARPas d'un point de vue dangereux.
JARrequest non pris en charge
Par paire subAucun, public seulement
Inscription dynamiqueMéthode originale d'OpenAI

De plus, dans l'utilisation de la technologie,

"request_uri_parameter_supported": false,
"request_parameter_supported": false

Par conséquent, nous n'utilisons actuellement pas les méthodes de type objet JAR/requête. https://auth.openai.com/.well-known/openid-configuration Cela est visible sur l'image.

Points de conception particulièrement remarquables

Si cela ne tenait qu'à moi, du point de vue de la normalisation, je me pencherais particulièrement sur les quatre points suivants.

① Séparation de « Connexion » et de « Droit d’accès à l’IA »

C'est un bon design.

authentication != authorization != subscription entitlement

C'est relativement clair.

② L'abonnement ChatGPT devient un accès aux ressources OAuth

chatgpt.tokens.use.direct Il ne s'agit pas simplement d'une portée d'API, mais en réalité,

« Ce client risque d'utiliser tout l'espace d'abonnement disponible pour cet abonné ChatGPT. »

Voilà la délégation.

À partir de l'« action de données utilisateur/API » que supposait l'OAuth traditionnel,délégation des droits économiques Le sens du terme « portée » s'est élargi.

C’est assez intéressant du point de vue des paiements par mandat et de la délégation de pouvoirs.

③ L'inscription du client est liée à l'utilisateur.

Émis dans le flux OSS client_id が,

user + selected workspace

Il est lié à24

C'est conventionnel

client_id = software application/deployment

C'est assez différent du modèle OAuth.

Plutôt

client_id ≈ user-authorized agent registration

で す.

④ Ajouter l'identité de l'hôte à OAuth.

さ ら に,

client
user
workspace
host

Nous les traitons séparément.

Cela deviendra important pour l'IA des agents à l'avenir.

Principal
Agent
Client
Runtime
Device/Host

Cette structure est assez similaire à la séparation des identités.

En revanche, certains points me préoccupent.

Voici la partie du protocole qui nous intéresse.

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

Cependant, actuellement,

ext_agent_host_id

Bien qu'elle existe, la possession de la clé privée de l'hôte n'est pas vérifiée.

Par conséquent, l'identification actuelle de l'hôte est :

identification

Et,

cryptographic binding

n'est pas25.

De plus, le jeton d'accès est porteur.

S'il s'agit d'un travail à forte valeur ajoutée, alors à l'avenir,

JKT / DPoP / attested key

Je pense qu'il y a beaucoup de place pour la liaison dans des endroits comme celui-ci. C'est essentiellement une implémentation FAPI.

ま と め

Se connecter avec ChatGPT est assez simple pour un OIDC.

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

De plus, le profil unique d'OpenAI est le suivant :

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

Ajouter,

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

Nous en sommes conscients.

Ce qui est particulièrement important, c'est que ce n'est pas simplement une « version ChatGPT de la connexion avec Google ».Système d'autorisation de fournisseur d'identité + d'accès des abonnés + d'enregistrement des agents, clients et hôtes Voici la combinaison.

En matière de normalisation,RFC 8707 / RFC 8252 Bien qu'il repose fortement sur OpenID Connect Core, il n'étend que l'enregistrement dynamique des clients et la liaison agent-hôte avec ses propres extensions personnalisées.Organiser le document de cette manière le rend plus facile à comprendre.

脚注

  1. Récapitulatif de l'OpenAI DevDay 2026
  2. Document de découverte OpenAI OIDC
  3. Développeurs OpenAI
  4. Développeurs OpenAI : Sur votre site web
  5. Pour une authentification standard basée uniquement sur l'identité, l'artefact requis est id_token. Il n'est pas nécessaire d'utiliser un access_token ou un refresh_token OpenAI ; ces éléments ne font pas partie du contrat client standard d'authentification uniquement. Développeurs OpenAI
  6. Développeurs OpenAI – Connectez-vous avec ChatGPT – Sur votre site web
  7. OpenAI
  8. Développeurs OpenAI : Inscriptions et connexion
  9. RFC 8707 : Indicateurs de ressources pour OAuth 2.0 | Éditeur de RFC
  10. Développeurs OpenAI
  11. Développeurs OpenAI – Se connecter avec ChatGPT – Modèles et inférence
  12. Développeurs OpenAI – Se connecter avec ChatGPT – Modèles et inférence
  13. Développeurs OpenAI – Se connecter avec ChatGPT – Aperçu des limitations
  14. Développeurs OpenAI : Inscription et connexion
  15. Développeurs OpenAI – Se connecter avec ChatGPT – Inscription et connexion
  16. Développeurs OpenAI - Se connecter avec ChatGPT - Aperçu
  17. Développeurs OpenAI
  18. Développeurs OpenAI – Se connecter avec ChatGPT – Vue d'ensemble
  19. Développeurs OpenAI – Se connecter avec ChatGPT – Inscription et connexion
  20. Développeurs OpenAI - SIWC - Inscription et connexion
  21. Développeurs OpenAI – Se connecter avec ChatGPT – Inscription et connexion
  22. Développeurs OpenAI – Dans votre plugin ChatGPT
  23. Développeurs OpenAI – Connectez-vous avec ChatGPT – Dans votre plugin ChatGPT
  24. Développeurs OpenAI – Se connecter avec ChatGPT – Vue d'ensemble
  25. Développeurs OpenAI : SIWC – Aperçu