323 VISTAS
Pinterest LinkedIn LINHA

(Em edição: Última atualização em 02/10/2026 às 12:39 JST) A OpenAI anunciou no DevDay 2026 em 29 de setembro.Entrar com o ChatGPT (SIWC) Anunciamos oficialmente. Gostaria de verificar pessoalmente e escrever um artigo sobre isso, mas não tenho tempo agora. Portanto, estou publicando abaixo o rascunho que o próprio ChatGPT preparou. Se encontrar algum erro, por favor, me avise no X.

O SIWC foi lançado pela OpenAI. Recurso de provedor OpenID Connect / servidor de autorização OAuthNo entanto, na realidade, as duas funcionalidades seguintes pertencem à mesma marca:

  1. Login de identidade
    Utilizando uma conta ChatGPT, um método quase padrão Código de autorização OpenID Connect + PKCE.
  2. dificuldades de planejamento do ChatGPT
    O limite de uso incluído nos contratos ChatGPT, como Plus/Pro, pode ser utilizado em aplicativos externos de código aberto ou compatíveis. Um mecanismo para usar a API de Respostas, expondo-a a um Token de Acesso OAuth..

Este último é bastante distinto. Trata-se mais de uma extensão de "fazer login com o ChatGPT".Identidade do assinante do ChatGPT + direito de inferência delegada Este é um mecanismo para transmitir informações a aplicativos externos usando OAuth. A própria OpenAI afirma explicitamente que a identidade e o uso do plano são permissões separadas. 1

A OpenAI começou a implementar seu recurso de Identidade em alguns sites/plugins parceiros em 23 de setembro de 2026 e anunciou oficialmente sua implementação, incluindo o uso do plano ChatGPT, no DevDay 2026, em 29 de setembro.

Login de identidade

A parte de identidade é praticamente o padrão OpenID Connect.

O documento de descoberta de produção da OpenAI está, na verdade, disponível publicamente. 2.

Os metadados principais são os seguintes:

項目値
Emissorahttps://auth.openai.com
Ponto final de autorizaçãohttps://auth.openai.com/api/accounts/authorize
Ponto final do tokenhttps://auth.openai.com/api/accounts/oauth/token
Ponto de extremidade do UserInfohttps://auth.openai.com/api/accounts/oauth/userinfo
Ponto final de revogaçãohttps://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
tipo_de_respostacode Somente
tipo de concessãoauthorization_code, refresh_token
PKCES256
tipo de assuntopublic
Assinatura de token de IDRS256
autenticação de ponto de extremidade de tokenclient_secret_basic, client_secret_post, none

Em outras palavras, a forma básica é,

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

で す.

Ao usar apenas a identidade em um site, a solicitação de autorização é quase idêntica a um OIDC típico no exemplo da própria 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

Escopo é

openid
profile
email

で す.

profile Então, nome/foto etc.email Em seguida, solicitaremos um endereço de e-mail e uma confirmação de verificação por e-mail. email_verified É fornecida uma lista de reivindicações OIDC padrão, incluindo as seguintes.3

Verificação de Token de ID

A Parte Confiante (RP) verificará o Token de ID usando JWKS como de costume.

A OpenAI afirma explicitamente,

iss
aud
exp
nonce
sub
signature

Eles estão solicitando que você verifique isso.

aud é RP client_id,iss は

https://auth.openai.com

で す. 4

Com relação à chave de identidade em RP, a OpenAI afirma:

issuer + client_id + sub

Recomendamos que você o guarde.

Também é importante,

Não vincule automaticamente contas existentes usando apenas o e-mail.

Esse é o ponto. A correspondência de e-mails não é considerada prova de propriedade da conta. Isso está correto.

O tipo de assunto no Discovery é:

"subject_types_supported": ["public"]

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

Portanto, atualmente não estamos anunciando estudos em pares.

A autenticação somente de identidade não utiliza tokens de acesso.

Este é um projeto bastante interessante.

Em um SIWC típico de um site, o OpenAI é suportado.

Para autenticação somente de identidade, o artefato necessário é id_tokenNão solicite um token de acesso ou token de atualização da OpenAI.

Diz-se que5.

O endpoint UserInfo foi descoberto, mas o exemplo padrão de login web do SIWC não pressupõe a presença do UserInfo. Ainda não verifiquei, então não sei o que acontece se você acessá-lo com um token de acesso. Entendo a necessidade de evitar retornar um token de acesso em casos que exigem apenas identidade (mas ele precisa ser retornado porque a RFC 6749 exige isso). Acho que seria melhor para o Grupo de Trabalho OAuth criar um novo tipo de concessão. No entanto, atualmente, parece que ele é retornado porque precisa ser retornado (← isso precisa ser confirmado). Então, onde o token de acesso é usado? Explicarei isso mais tarde.

Cliente público / Cliente confidencial

Eu tenho ambos.

Cliente público

A autenticação por token no endpoint é:

none

Então, vamos usar a 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

Exemplos atualmente documentados incluem:

client_secret_basic

で す.

Além disso, mantém o PKCE mesmo com um cliente confidencial.6.

A própria descoberta

client_secret_basic
client_secret_post
none

Esses três métodos são anunciados.7.

Utilização do plano ChatGPT: Utilização de modelos OpenAI com uma assinatura.

Problemas para obter um token de acesso ao plano ChatGPT

Agora, como mencionado no início, o login com o ChatGPT tem "dificuldades de planejamento do ChatGPTExiste um recurso chamado "API de Respostas da OpenAI". Ele permite que aplicativos externos deleguem permissões para chamar a API de Respostas da OpenAI a partir do plano ChatGPT do usuário, utilizando OAuth. Com isso, o aplicativo externo (cliente) pode especificar um modelo da OpenAI e realizar diversas ações (como ler a web usando ferramentas, ler e gravar arquivos, processar informações e exibir os resultados).

fluxograma TD A["Aplicação"] B["API de Respostas"] C["Modelo"] D["Busca na Web"] E["Arquivos"] F["Código"] G["Computador"] H["Servidor MCP"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

Então

API de Respostas = Primitivas básicas de execução de agentes usando modelos OpenAI

Seria melhor entender dessa forma.

Para realizar essa delegação, é necessário um token de acesso. No SIWC, o cliente utiliza o seguinte na solicitação de autenticação:scopeVocê o obtém solicitando-o.8.

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

Além disso,

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

Isso também deve ser incluído na Solicitação de Autorização e na Solicitação de Token.

Isto está em forma RFC 8707 Indicadores de recursos para OAuth 2.0 9 Sim. RFC 8707 é resourceEsse mecanismo permite especificar o servidor de recursos de destino usando um URI absoluto.

Portanto, conceitualmente,

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

と な り ま す.

Token de acesso aud Também

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

で す10Este não é um endpoint de informações do usuário.

Exemplo de um token de acesso

A carga útil publicada pela OpenAI está estruturada conceitualmente da seguinte forma.

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

Em outras palavras, o Token de Acesso também é um JWT.

A expectativa de vida é,

  • Token de acesso: 1 時間
  • Token de atualização: 30 日
  • Rotação do token de atualização a cada atualização
  • O novo Token de Atualização terá novamente uma validade de 30 dias.

で す.

A documentação atual não utiliza restrições de remetente como o DPoP, e a API de Respostas usa o padrão normal.

Authorization: Bearer <ACCESS_TOKEN>

Vou enviar assim mesmo.11.

Consumindo uma assinatura do ChatGPT com a API de Respostas

Por exemplo,

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

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

で す.

A OpenAI está atualmente fornecendo informações sobre a utilização do plano SIWC.

store: false
stream: true

Isso é necessário. 12.

Em outras palavras, não se trata simplesmente de substituir uma chave de API comum por um token OAuth.

Algumas funcionalidades da API de Respostas também são limitadas; por exemplo, na versão prévia atual,

  • background
  • persistente conversation
  • previous_response_id sobre HTTP
  • Hospedagem de MCP/conectores
  • geração de imagem
  • Pesquisa de arquivos
  • Intérprete de código
  • uso nativo de computador

Esses serviços não estão disponíveis.13

portanto Uma assinatura de API implementada usando OAuth.Também é ligeiramente diferente.

extensões proprietárias da SIWC

Quarto método de registro de cliente: dynamic_agent_client

Com o OAuth padrão, você pode pré-registrar o cliente ou usar o endpoint de registro dinâmico de cliente (RFC 7591). No contexto do OpenID, usar a Federação OpenID também é uma opção atualmente.

O fluxo de código aberto (OSS) da SIWC é diferente de ambos.

Na solicitação de autorização inicial,

client_id=dynamic_agent_client

Isso utiliza um pseudo-cliente especial.

Além disso,

agent_name_hint
ext_agent_host_id

Adicione-o.14

por exemplo:

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 o retorno de chamada é,

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

EO client_id oficial é fornecido aqui.15Resumindo, é como realizar o cadastro do cliente ao mesmo tempo que a solicitação de autorização.

Em seguida, o endpoint do token será

dynamic_agent_client

Em vez disso, esta recém-publicada

oaiapp_xxxxx

Eu vou enviar.

Isso é claramente diferente da RFC 7591 Dynamic Client Area.

A RFC 7591 normalmente afirma,

POST registration_endpoint
       ↓
client_id
client_secret...

で す.

O fluxo SIWC OSS é,

sequenceDiagram autonumber participante C como Cliente/Agente OSS participante B como Navegador participante AS como Endpoint de Autorização OpenAI participante U como Usuário C->>C: Gerar estado, nonce, verificador_de_código / desafio_de_código C->>B: Abrir URL de autorização B->>AS: GET /api/accounts/authorize client_id=dynamic_agent_client tipo_de_resposta=código redirect_uri=http://127.0.0.1:PORTA/callback escopo=openid perfil e-mail ... desafio_de_código=... code_challenge_method=S256 AS->>U: Autenticar usuário U-->>AS: Autenticação concluída AS->>U: Mostrar consentimento/registro do aplicativo U-->>AS: Aprovar Nota sobre AS: Criar/registrar um cliente concreto e emita client_id = oaiapp_... AS-->>B: Redirecionamento HTTP para redirect_uri ?code=CÓDIGO_DE_AUTENTICAÇÃO &estado=ESTADO &client_id=oaiapp_... B-->>C: GET /callback cliente=CÓDIGO_DE_AUTENTICAÇÃO estado=ESTADO client_id=oaiapp_... Nota sobre C: Armazene oaiapp_... client_id emitido Use-o para a solicitação de token. não é cliente de agente dinâmico

で す.

Portanto,

Registro dinâmico mediado pelo usuário incorporado em uma solicitação de autorização.

Essa é a interpretação correta.

RFC 7591Seria melhor não chamar isso de Registro Dinâmico de Cliente Compatível.

ext_agent_host_id

Essa também é uma extensão interessante da OpenAI.

Além do cliente OSS,

agent host

Existe um conceito chamado isso.

Por exemplo,

fluxograma TD A["Um registro de 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 é o modelo.16.

Atualmente, a OpenAI utiliza IDs de host.

Recomendação

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

RFC 9278 JWK Thumbprint URI

em vez de

urn:uuid:<uuid>

または

did:key:...

Eles reconhecem isso.17

No entanto, o que é extremamente importante neste momento é,

A OpenAI não verifica a posse da chave privada, mesmo quando se utiliza a impressão digital JWK.

Essa é a questão.18

Portanto,

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

で す.

Atualmente, trata-se simplesmente de um identificador de host estável.

Como aplicativo nativo, ele segue rigorosamente a RFC 8252.

Em software livre para desktop/cliente,

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

É usado.

localhost Não use o literal de IP. 127.0.0.1 Esta é uma solicitação. Somente o número da porta pode ser alterado a cada login.19.

Isso está de acordo com o redirecionamento da interface de loopback na RFC 8252.RFC 8252Ele próprio,

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

Isso define e exige o uso de PKCE em aplicativos nativos.

Retornando ao login e id_token_hint

Após o cadastro, da próxima vez em diante,

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

Você pode usá-lo.

Curiosamente, a OpenAI anteriormente Mesmo que o token de identificação tenha expirado... id_token_hint Pode ser usado comoEstá claramente declarado.20.

こ れ はOpenID Connect Core 1.0Não é que esteja fora do escopo.

O próprio núcleo OIDC,

id_token_hint Esta é uma dica que indica a sessão autenticada atual ou anterior.

E se foi emitido pelo OP,exp Recomendamos aceitar sessões recentes, mesmo que o prazo tenha expirado.

Portanto, esta parte é uma implementação OIDC bastante típica.

Existem algumas inconsistências nos metadados de descoberta.

Do ponto de vista da padronização, esta é atualmente a área de maior preocupação.

Documento de descoberta:

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

Em

resource.invoke
chatgpt.tokens.use.direct

Não existe. OpenAI

No entanto, a documentação oficial da SIWC afirma claramente:

offline_access
resource.invoke
chatgpt.tokens.use.direct

Estamos solicitando21.

Isso não é necessariamente uma falha fatal em termos de especificações.

A capacidade de utilização do plano SIWC não pode ser descoberta apenas a partir dos metadados do Discovery.

Portanto, seria melhor adicioná-lo.

Da mesma forma,

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

Estamos utilizando-o conforme a RFC 8707, mas não há metadados específicos do SIWC para descoberta da capacidade de uso do plano.

Portanto, a situação atual é,

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

Você precisa ler os dois.

No caso do plugin ChatGPT, o OAuth é duplicado.

A integração com o plugin ChatGPT possui uma estrutura ainda mais interessante.

De acordo com a explicação da OpenAI,

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

で す22.

Transação externa

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

transação interna

Plugin → OpenAI:

openid profile email

SIWC por

O plugin verifica o token de identificação da OpenAI para identificar a conta local e, em seguida, reinicia o OAuth externo.23.

Portanto,

O SIWC não substitui o servidor de autorização OAuth do próprio plugin.

Isso é importante.

Será incluído como uma camada interna da Federação de Identidades.

Identidade e autorização são intencionalmente separadas.

Em resumo:

fluxograma TD A["Conta OpenAI / ChatGPT"] A -->|"Autenticação OIDC openid profile email"| B["Aplicativo"] B -->|"Sessão própria do aplicativo"| C["Sessão local"] B -->|"Autorização opcional chatgpt.tokens.use.direct resource.invoke"| D["Token de acesso OAuth"] D -->|"Token de portador"| E["API de respostas OpenAI"]

O simples login com identificação não é suficiente.

  • Conversas ChatGPT
  • memória
  • arquivos
  • dados de faturamento
  • Chave API

Estas não serão cruzadas. Central de Ajuda OpenAI

ま た chatgpt.tokens.use.direct Sem ele, você não pode realizar uma inferência usando um plano ChatGPT, mesmo que tenha obtido um token de ID válido. Desenvolvedores OpenAI

Essa separação é bastante importante do ponto de vista do design.

Do ponto de vista da segurança

Resumindo o perfil atual do ponto de vista da segurança OAuth/OIDC,

項目SIWC
Código de autorização○
PKCE S256○ / Essencialmente necessário
state○
OIDC nonce○
URI de redirecionamento exata○
Aplicativo nativo navegador externo○
Redirecionamento de loopback○
Vídeo revigorante○
Estilo RFC 8707 resource○
AT com restrição de remetenteNão encontrado nos documentos
DPoPNão encontrado nos documentos
mTLSNão encontrado nos documentos
PARNão do ponto de vista do perigo.
JARrequest não suportado
Emparelhados subNenhum, somente público
Registro dinâmicoMétodo original da OpenAI

Além disso, no uso da tecnologia,

"request_uri_parameter_supported": false,
"request_parameter_supported": false

Portanto, atualmente não utilizamos métodos do tipo objeto JAR/request. https://auth.openai.com/.well-known/openid-configuration Isso pode ser visto na imagem.

Pontos de design de particular interesse

Se dependesse de mim, do ponto de vista da padronização, eu analisaria particularmente os quatro pontos a seguir.

① Separação de "Autenticação" e "Direito à IA"

Este é um bom projeto.

authentication != authorization != subscription entitlement

Isso é relativamente claro.

② A assinatura do ChatGPT se torna Acesso a Recursos OAuth

chatgpt.tokens.use.direct Isso não é apenas um escopo de API, mas na realidade,

"Este cliente pode utilizar todo o espaço de assinatura reservado para este assinante do ChatGPT."

Essa é a delegação.

A partir dos "dados do usuário/ação da API" que o OAuth tradicional pressupunha,delegação de direitos econômicos O significado de "escopo" foi ampliado.

Isso é bastante interessante do ponto de vista dos Pagamentos Agentic e da autoridade delegada.

③ O cadastro do cliente é vinculado ao usuário.

Emitido no fluxo OSS client_id Mas

user + selected workspace

Está fadado a24

Isso é convencional

client_id = software application/deployment

Isso é bem diferente do modelo OAuth.

Pelo contrário

client_id ≈ user-authorized agent registration

で す.

④ Adicione a identidade do host ao OAuth.

Além disso,

client
user
workspace
host

Nós os tratamos separadamente.

Isso se tornará importante no futuro da IA ​​de agentes.

Principal
Agent
Client
Runtime
Device/Host

Essa estrutura é bastante semelhante à separação de identidades.

Por outro lado, existem alguns pontos que me preocupam.

Esta é a parte relevante do projeto do protocolo.

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

No entanto, atualmente,

ext_agent_host_id

Embora exista, a posse da chave privada do host não é verificada.

Portanto, a identificação atual do hospedeiro é,

identification

E,

cryptographic binding

não é25.

Além disso, o token de acesso é do tipo Bearer.

Se se referir a trabalho de alto valor, então, no futuro,

JKT / DPoP / attested key

Acho que há muito espaço para integração em locais como este. É basicamente uma implementação de FAPI.

ま と め

Fazer login com o ChatGPT é bastante simples para um OIDC.

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

Além disso, o perfil único da OpenAI é:

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

Adicionar,

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

Estamos percebendo isso.

O que é particularmente importante é que esta não é simplesmente uma "versão ChatGPT do 'Entrar com o Google'".Provedor de identidade + autorização de direitos do assinante + sistema de registro de agente/cliente/host Esta é a combinação.

Em termos de padronização,RFC 8707 / RFC 8252 Embora dependa fortemente do OpenID Connect Core, ele estende apenas o registro dinâmico de clientes e a vinculação agente-host com suas próprias extensões personalizadas.Organizar dessa forma facilita a compreensão.

nota de rodapé

  1. OpenAI: Uma retrospectiva do DevDay 2026
  2. Documento de Descoberta OIDC da OpenAI
  3. Desenvolvedores OpenAI
  4. Desenvolvedores da OpenAI: Em seu site
  5. Para login padrão somente com identificação, o artefato necessário é o id_token. Não é necessário um access_token ou refresh_token da OpenAI; eles não fazem parte do contrato padrão do cliente somente com identificação. Desenvolvedores OpenAI
  6. Desenvolvedores da OpenAI – Faça login com o ChatGPT – No seu site
  7. OpenAI
  8. Desenvolvedores da OpenAI: Registros e login
  9. RFC 8707: Indicadores de Recursos para OAuth 2.0 | Editor de RFC
  10. Desenvolvedores OpenAI
  11. Desenvolvedores da OpenAI – Login com ChatGPT – Modelos e inferência
  12. Desenvolvedores da OpenAI – Login com ChatGPT – Modelos e inferência
  13. Desenvolvedores da OpenAI – Faça login com o ChatGPT – Limitações da versão prévia
  14. Desenvolvedores da OpenAI: Registro e login
  15. Desenvolvedores da OpenAI – Faça login com o ChatGPT – Cadastro e login
  16. Desenvolvedores da OpenAI - Faça login com o ChatGPT - Visão geral
  17. Desenvolvedores OpenAI
  18. Desenvolvedores da OpenAI – Iniciar sessão com o ChatGPT – Visão geral
  19. Desenvolvedores da OpenAI – Login com ChatGPT – Cadastro e login
  20. OpenAI Developers-SIWC - Registro e login
  21. Desenvolvedores da OpenAI – Login com ChatGPT – Cadastro e login
  22. Desenvolvedores da OpenAI – No seu plugin ChatGPT
  23. Desenvolvedores da OpenAI – Faça login com o ChatGPT – No seu plugin do ChatGPT
  24. Desenvolvedores da OpenAI – Login com ChatGPT – Visão geral
  25. Desenvolvedores da OpenAI: SIWC – Visão geral