320 PUNTOS DE VISTA
Pinterest LinkedIn LÍNEA

(Edición en curso: Última actualización 2026-10-02 12:39 JST) OpenAI fue anunciado en DevDay 2026 el 29 de septiembre.Iniciar sesión con ChatGPT (SIWC) Ya lo hemos anunciado oficialmente. Me gustaría revisarlo personalmente y escribir un artículo al respecto, pero ahora mismo no tengo tiempo. Así que, a continuación, publico el borrador que ChatGPT elaboró. Si encuentran algún error, por favor, avísenme en X.

SIWC fue lanzado por OpenAI. Función de proveedor de OpenID Connect / servidor de autorización OAuthSin embargo, en realidad, las dos características siguientes pertenecen a la misma marca:

  1. Iniciar sesión con su identidad
    Usando una cuenta de ChatGPT, un método casi estándar Código de autorización de OpenID Connect + PKCE.
  2. Dificultades de planificación de ChatGPT
    El límite de uso incluido en los contratos de ChatGPT, como Plus/Pro, puede utilizarse desde aplicaciones externas de código abierto o compatibles. Un mecanismo para utilizar la API de Respuestas exponiéndola a un token de acceso OAuth..

Este último es bastante distintivo. Es más bien una extensión de "iniciar sesión con ChatGPT".Identidad del suscriptor de ChatGPT + derecho de inferencia delegada Este es un mecanismo para transmitir información a aplicaciones externas mediante OAuth. OpenAI declara explícitamente que la identidad y el uso del plan son permisos independientes. 1

OpenAI comenzó a implementar su función Identity en algunos sitios/plugins asociados el 23 de septiembre de 2026, y anunció oficialmente su implementación, incluido el uso del plan ChatGPT, en DevDay 2026 el 29 de septiembre.

Iniciar sesión con su identidad

La parte de identidad es prácticamente estándar, similar a OpenID Connect.

El documento de descubrimiento de producción de OpenAI está disponible públicamente. 2.

Los metadatos principales son los siguientes:

Proyectovalor
Emisorhttps://auth.openai.com
Punto final de autorizaciónhttps://auth.openai.com/api/accounts/authorize
Punto final del tokenhttps://auth.openai.com/api/accounts/oauth/token
Punto final de información del usuariohttps://auth.openai.com/api/accounts/oauth/userinfo
Punto final de revocaciónhttps://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
tipo_respuestacode の み
subvención_tipoauthorization_code, refresh_token
PKCES256
tipo de temapublic
Firma de tokens de identificaciónRS256
autenticación de punto final de tokenclient_secret_basic, client_secret_post, none

En otras palabras, la forma básica es,

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

で す.

Cuando se utiliza únicamente Identity en un sitio web, la solicitud de autorización es casi idéntica a una OIDC típica en el ejemplo de 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

El alcance es

openid
profile
email

で す.

profile Entonces, nombre/imagen, etc.email Luego solicitaremos un correo electrónico y una verificación de correo electrónico. email_verified Se proporciona una lista de reclamaciones estándar de OIDC, que incluye las siguientes.3

Verificación del token de identificación

La parte confiable (RP) verificará el token de identificación utilizando JWKS como de costumbre.

OpenAI declara explícitamente:

iss
aud
exp
nonce
sub
signature

Te piden que verifiques esto.

aud es RP client_id,iss は

https://auth.openai.com

で す. 4

Respecto a la clave de identidad en RP, OpenAI afirma:

issuer + client_id + sub

Recomendamos conservarlo.

También es importante,

No vincule automáticamente las cuentas existentes utilizando únicamente el correo electrónico.

Este es el punto. La coincidencia de correos electrónicos no se considera prueba de propiedad de la cuenta. Este es el diseño correcto.

El tipo de sujeto en Discovery es:

"subject_types_supported": ["public"]

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

Por lo tanto, actualmente no estamos anunciando sujetos para análisis por pares.

El modelo de solo identidad no utiliza tokens de acceso.

Este es un diseño bastante interesante.

En el SIWC típico de un sitio web, se admite OpenAI.

Para el inicio de sesión solo con identidad, el artefacto requerido es id_tokenNo solicite un token de acceso ni un token de actualización de OpenAI.

Eso es lo que es.5.

Se ha descubierto el endpoint UserInfo, pero el ejemplo estándar de inicio de sesión web de SIWC no presupone su presencia. Aún no lo he comprobado, así que desconozco qué ocurre al acceder con un token de acceso. Entiendo la necesidad de evitar devolver un token de acceso en casos de solo identidad (pero debe devolverse porque la RFC 6749 lo exige). Creo que lo mejor sería que el Grupo de Trabajo de OAuth creara un nuevo tipo de concesión. Sin embargo, actualmente parece que se devuelve porque es obligatorio (esto debe confirmarse). Entonces, ¿dónde se utiliza el token de acceso? Lo explicaré más adelante.

Cliente público / Cliente confidencial

Tengo ambos.

Cliente público

La autenticación del punto final del token es:

none

Entonces, utilizaremos 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 confidencial

Entre los ejemplos documentados actualmente se incluyen:

client_secret_basic

で す.

Además, mantiene el PKCE incluso con un cliente confidencial.6.

El descubrimiento en sí

client_secret_basic
client_secret_post
none

Estos tres métodos se anuncian.7.

Uso del plan ChatGPT: Uso de modelos OpenAI con una suscripción.

Obtención de un token de acceso para problemas con el plan ChatGPT

Ahora, como se mencionó al principio, Iniciar sesión con ChatGPT tiene "Dificultades de planificación de ChatGPTExiste una función llamada "API de respuestas de OpenAI". Esta permite que las aplicaciones externas deleguen permisos para llamar a la API de respuestas de OpenAI desde el plan ChatGPT del usuario mediante OAuth. De esta forma, la aplicación externa (cliente) puede especificar un modelo de OpenAI y realizar diversas acciones (como navegar por la web con herramientas, leer y escribir archivos, procesar información y mostrar los resultados).

Diagrama de flujo TD A["Aplicación"] B["API de respuestas"] C["Modelo"] D["Búsqueda web"] E["Archivos"] F["Código"] G["Computadora"] H["Servidor MCP"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

す の で 、

API de respuestas = Primitivas básicas de ejecución de agentes utilizando modelos de OpenAI

Sería mejor entenderlo de esa manera.

Ahora bien, para realizar esta delegación, se requiere un token de acceso, y en SIWC, el cliente utiliza lo siguiente en la solicitud de autenticación:scopeSe obtiene solicitándolo.8.

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

Además,

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

Esto también debe incluirse en la solicitud de autorización y en la solicitud de token.

Esto está en forma RFC 8707 Indicadores de recursos para OAuth 2.0 9 Sí. RFC 8707 es resourceEste mecanismo permite especificar el servidor de recursos de destino mediante una URI absoluta.

Por lo tanto, conceptualmente,

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

と な り ま す.

Token de acceso aud también,

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

で す10Este no es un punto final de información de usuario.

Ejemplo de token de acceso

La carga útil publicada por OpenAI está estructurada conceptualmente de la siguiente manera.

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

En otras palabras, el token de acceso también es un JWT.

La esperanza de vida es,

  • Ficha de acceso: 1 horas
  • Token de actualización: 30 días
  • Rotación del token de actualización con cada actualización
  • El nuevo token de actualización volverá a tener una validez de 30 días.

で す.

La documentación actual no utiliza restricciones de remitente como DPoP, y la API de respuestas utiliza el método normal.

Authorization: Bearer <ACCESS_TOKEN>

Lo enviaré tal cual.11.

Consumir una suscripción de ChatGPT con la API de Respuestas

Por ejemplo,

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

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

で す.

OpenAI está proporcionando actualmente información sobre el uso del plan SIWC.

store: false
stream: true

Esto es obligatorio. 12.

En otras palabras, no se trata simplemente de reemplazar una clave API normal por un token OAuth.

Algunas características de la API de Respuestas también están limitadas; por ejemplo, en la vista previa actual,

  • background
  • persistente conversation
  • previous_response_id a través de HTTP
  • Alojar MCP/conectores
  • generación de imágenes
  • búsqueda de archivos
  • Intérprete de código
  • uso nativo de la computadora

Estos servicios no están disponibles.13

por lo tanto Una suscripción a la API que se ha convertido a OAuth.También es ligeramente diferente.

Extensiones propietarias de SIWC

Cuarto método de registro de cliente: dynamic_agent_client

Con OAuth estándar, se puede preinscribir al cliente o usar el punto final de registro dinámico de clientes RFC 7591. En el contexto de OpenID, usar OpenID Federation también es una opción actualmente.

El flujo de código abierto de SIWC es diferente de ambos.

En la solicitud de autorización inicial,

client_id=dynamic_agent_client

Esto utiliza un pseudocliente especial.

さ ら に,

agent_name_hint
ext_agent_host_id

Añádelo.14

Por ejemplo:

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

Y la función de devolución de llamada es,

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

Próximo,El ID de cliente oficial se emite aquí.15En resumen, es como realizar el registro del cliente al mismo tiempo que la solicitud de autorización.

Posteriormente, el punto final del token será

dynamic_agent_client

Más bien, este recién emitido

oaiapp_xxxxx

Lo enviaré.

Esto es claramente diferente del Área de Cliente Dinámica de RFC 7591.

El RFC 7591 normalmente establece:

POST registration_endpoint
       ↓
client_id
client_secret...

で す.

El flujo de SIWC OSS es,

sequenceDiagram autonumber participante C como cliente/agente OSS participante B como navegador participante AS como punto final de autorización de OpenAI participante U como usuario C->>C: Generar estado, nonce, code_verifier / code_challenge C->>B: Abrir URL de autorización B->>AS: GET /api/accounts/authorize client_id=dynamic_agent_client tipo_de_respuesta=código redirect_uri=http://127.0.0.1:PORT/callback ámbito=perfil openid correo electrónico ... code_challenge=... code_challenge_method=S256 AS->>U: Autenticar usuario U-->>AS: Autenticación completada AS->>U: Mostrar consentimiento / registro de la aplicación U-->>AS: Aprobar Nota sobre AS: Crear/registrar un cliente concreto y emitir client_id = oaiapp_... AS-->>B: Redirección HTTP a redirect_uri ?código=CÓDIGO_AUTORIZACIÓN &estado=ESTADO &client_id=oaiapp_... B-->>C: GET /callback cliente=CÓDIGO_AUTORIZACIÓN estado=ESTADO client_id=oaiapp_... Nota sobre C: Almacenó oaiapp_... client_id Úselo para la solicitud de token. no es un agente dinámico

で す.

Por lo tanto,

Registro dinámico mediado por el usuario integrado en una solicitud de autorización

Esa es la interpretación correcta.

RFC 7591Sería mejor no llamarlo Registro Dinámico de Clientes compatible.

ext_agent_host_id

Esta también es una extensión interesante de OpenAI.

Además del cliente OSS,

agent host

Existe un concepto llamado así.

Por ejemplo,

Diagrama de flujo TD A["Registro de un cliente 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"]

Este es el modelo.16.

Actualmente, OpenAI utiliza identificadores de host.

Recomendación

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

RFC 9278 URI de huella digital JWK

en lugar

urn:uuid:<uuid>

または

did:key:...

Lo reconocen.17

Sin embargo, lo que es extremadamente importante en este punto es:

OpenAI no verifica la posesión de la clave privada ni siquiera al usar la huella digital JWK.

Ese es el punto.18

Por lo tanto,

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

で す.

Actualmente, se trata simplemente de un identificador de host estable.

Al ser una aplicación nativa, se ajusta bastante al estándar RFC 8252.

En el escritorio/cliente OSS,

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

Es usado

localhost No utilice el literal IP 127.0.0.1 Esta es una solicitud. Solo se puede cambiar el número de puerto para cada inicio de sesión.19.

Esto es coherente con la redirección de interfaz de bucle invertido descrita en la RFC 8252.RFC 8252Él mismo,

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

Esto define y exige el uso de PKCE en aplicaciones nativas.

Volver a iniciar sesión y id_token_hint

Una vez que se registre, a partir de la próxima vez,

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

Puedes usarlo.

Curiosamente, OpenAI anteriormente Aunque el token de identificación haya caducado... id_token_hint Puede utilizarse comoEstá claramente indicado.20.

esOpenID Connect Core 1.0No es que esté fuera del alcance.

El núcleo OIDC en sí mismo,

id_token_hint Esto es una pista que indica la sesión autenticada actual o pasada.

Y si fue emitido por OP,exp Recomendamos aceptar las sesiones recientes aunque haya expirado el plazo.

Por lo tanto, esta parte es una implementación OIDC bastante típica.

Existen algunas inconsistencias en los metadatos de Discovery.

Desde el punto de vista de la estandarización, esta es actualmente el área que suscita mayor preocupación.

Documento de descubrimiento:

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

En

resource.invoke
chatgpt.tokens.use.direct

No hay OpenAI

Sin embargo, la documentación oficial de SIWC establece claramente:

offline_access
resource.invoke
chatgpt.tokens.use.direct

Estamos solicitando21.

Esto no es necesariamente un defecto fatal en términos de especificaciones,

La capacidad de uso del plan SIWC no se puede descubrir únicamente a partir de los metadatos de Discovery.

Por lo tanto, sería mejor agregarlo.

Del mismo modo,

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

Lo estamos utilizando de la manera descrita en la RFC 8707, pero no existen metadatos de descubrimiento de capacidades de uso de planes específicos de SIWC.

Por lo tanto, la situación actual es:

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

Debes leer ambos.

En el caso del complemento ChatGPT, OAuth se duplica.

La integración con el plugin ChatGPT tiene una estructura aún más interesante.

Según la explicación de OpenAI,

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

で す22.

transacción externa

ChatGPT → Complemento:

/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

Transacción interna

Plugin → OpenAI:

openid profile email

SIWC por

El complemento verifica el token de ID de OpenAI para identificar la cuenta local y, a continuación, reinicia Outer OAuth.23.

Por lo tanto,

SIWC no reemplaza el servidor de autorización OAuth propio del complemento.

Eso es importante.

Se incluirá como una capa interna de la Federación de Identidad.

La identidad y la autorización están separadas intencionadamente.

En resumen:

Diagrama de flujo TD A["Cuenta OpenAI / ChatGPT"] A -->|"Autenticación OIDC" Correo electrónico del perfil openid"| B["Aplicación"] B -->|"Sesión propia de la aplicación"| C["Sesión local"] B -->|"Autorización opcional" chatgpt.tokens.use.direct resource.invoke"| D["Token de acceso OAuth"] D -->|"Token de portador"| E["API de respuestas de OpenAI"]

El inicio de sesión con la identidad por sí solo no es suficiente.

  • Conversaciones de ChatGPT
  • memoria
  • archivos
  • datos de facturación
  • Clave API

Estas no se cruzarán. Centro de ayuda de OpenAI

また chatgpt.tokens.use.direct Sin él, no podrá realizar una inferencia utilizando un plan ChatGPT, incluso si ha obtenido un token de identificación válido. Desarrolladores de OpenAI

Esta separación es muy importante desde el punto de vista del diseño.

Desde el punto de vista de la seguridad

Para resumir el perfil actual desde una perspectiva de seguridad OAuth/OIDC,

ProyectoSIWC
Código de Autorización○
PKCE S256○ / Esencialmente requerido
state○
OIDC nonce○
URI de redireccionamiento exacto○
Aplicación nativa navegador externo○
Redireccionamiento de bucle invertido○
Vídeo refrescante○
Estilo RFC 8707 resource○
AT con restricciones del remitenteNo se encuentra en los documentos.
DPoPNo se encuentra en los documentos.
mTLSNo se encuentra en los documentos.
PARNo desde un punto de vista peligroso.
JARrequest “nueva
Por parejas subNinguno, solo público
Registro dinámicoMétodo original de OpenAI

Además, en el uso de la tecnología,

"request_uri_parameter_supported": false,
"request_parameter_supported": false

Por lo tanto, actualmente no utilizamos métodos de tipo objeto JAR/request. https://auth.openai.com/.well-known/openid-configuration Esto se puede apreciar en la imagen.

Aspectos de diseño especialmente destacables

Si dependiera de mí, desde una perspectiva de estandarización, me fijaría especialmente en los siguientes cuatro puntos.

① Separación entre "Inicio de sesión" y "Autorización para IA"

Este es un buen diseño.

authentication != authorization != subscription entitlement

Eso está relativamente claro.

② La suscripción a ChatGPT se convierte en acceso a recursos OAuth.

chatgpt.tokens.use.direct Esto no es simplemente un ámbito de API, sino que en realidad,

"Este cliente podría agotar el cupo de suscripción para este suscriptor de ChatGPT."

Esa es la delegación.

Desde la "acción de datos de usuario/API" que asumía el OAuth tradicional,delegación de derechos económicos El significado de "alcance" se ha ampliado.

Esto resulta bastante interesante desde la perspectiva de los pagos a agentes y la autoridad delegada.

③ El registro del cliente está vinculado al usuario.

Emitido en el flujo OSS client_id Sin embargo,

user + selected workspace

Está obligado a24

Esto es convencional

client_id = software application/deployment

Esto es bastante diferente del modelo OAuth.

Más bien

client_id ≈ user-authorized agent registration

で す.

④ Agregue la identidad del host a OAuth.

さ ら に,

client
user
workspace
host

Los gestionamos por separado.

Esto cobrará importancia en la IA de agentes en el futuro.

Principal
Agent
Client
Runtime
Device/Host

Esta estructura es bastante similar a la separación de identidades.

Por otro lado, hay algunos puntos que me preocupan.

Esta es la parte relevante del diseño del protocolo.

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

Sin embargo, actualmente,

ext_agent_host_id

Aunque existe, la posesión de la clave privada del host no está verificada.

Por lo tanto, la identificación actual del huésped es:

identification

Y,

cryptographic binding

Eso es todo25.

Además, el token de acceso es de tipo portador.

Si se refiere a un trabajo de alto valor, entonces en el futuro,

JKT / DPoP / attested key

Creo que hay mucho margen para la vinculación en lugares como este. Básicamente, es una implementación de FAPI.

Resumen

Iniciar sesión con ChatGPT es bastante sencillo para un OIDC.

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

Además, el perfil único de OpenAI es:

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

Agregar,

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

Nos estamos dando cuenta de esto.

Lo que es particularmente importante es que esto no es simplemente una "versión de ChatGPT de Iniciar sesión con Google".Proveedor de identidad + autorización de derechos del suscriptor + sistema de registro de agente/cliente/host Esta es la combinación.

En términos de estandarización,RFC 8707 / RFC 8252 Si bien depende en gran medida de OpenID Connect Core, solo amplía el registro dinámico de clientes y la vinculación agente-host con sus propias extensiones personalizadas.Organizarlo de esta manera facilita su comprensión.

nota

  1. OpenAI: Un vistazo al DevDay 2026
  2. Documento de descubrimiento de OpenAI OIDC
  3. Desarrolladores de OpenAI
  4. Desarrolladores de OpenAI: En su sitio web
  5. Para el inicio de sesión estándar solo con identidad, el artefacto requerido es id_token. No se requiere un access_token ni un refresh_token de OpenAI; no forman parte del contrato de cliente estándar solo con identidad. Fuente: Desarrolladores de OpenAI
  6. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT en su sitio web.
  7. OpenAI
  8. Desarrolladores de OpenAI: Registros e inicio de sesión
  9. RFC 8707: Indicadores de recursos para OAuth 2.0 | Editor de RFC
  10. Desarrolladores de OpenAI
  11. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT: Modelos e inferencia.
  12. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT: Modelos e inferencia.
  13. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT - Vista previa de limitaciones
  14. Desarrolladores de OpenAI: Registro e inicio de sesión
  15. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT - Registro e inicio de sesión
  16. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT - Descripción general
  17. Desarrolladores de OpenAI
  18. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT - Descripción general
  19. Desarrolladores de OpenAI – Iniciar sesión con ChatGPT – Registro e inicio de sesión
  20. Desarrolladores de OpenAI - SIWC - Registro e inicio de sesión
  21. Desarrolladores de OpenAI – Iniciar sesión con ChatGPT – Registro e inicio de sesión
  22. Desarrolladores de OpenAI: en su complemento ChatGPT
  23. Desarrolladores de OpenAI: Inicia sesión con ChatGPT en tu plugin de ChatGPT.
  24. Desarrolladores de OpenAI: Iniciar sesión con ChatGPT - Descripción general
  25. Desarrolladores de OpenAI: SIWC – Descripción general