Passa al contenuto principale

Accedi con ChatGPT

Intermedio

Il 2 agosto 2026 OpenAI ha trasformato ChatGPT in un provider di identità. "Accedi con ChatGPT" è ora in beta pubblica, sullo stesso rack di pulsanti di Accedi con Google, Apple e Microsoft — e sta ridisegnando silenziosamente dove finirà a vivere buona parte dell'auth B2B. Questa pagina è per due lettori insieme: l'utente che vuole sapere cosa attraversa davvero il confine cliccando il pulsante, e lo sviluppatore che deve decidere se aggiungerlo alla propria app (e in caso positivo, come, senza rendere OpenAI una dipendenza portante).

What you'll learn
  • Capire cosa riceve un'app partner quando un utente accede con ChatGPT — e cosa no
  • Conoscere i sei partner del lancio e perché sono stati scelti (è un segnale, non una coincidenza)
  • Percorrere l'esatto flusso OAuth 2.1 + PKCE + OIDC che ChatGPT si aspetta sul tuo server
  • Vedere i controlli per admin enterprise già disponibili — e il default che sorprende
  • Conoscere le modalità di fallimento da progettare prima di mettere il pulsante sulla schermata di login

La versione da 60 secondi​

  • Cosa è stato lanciato. Un sistema di identità cross-platform: gli utenti possono creare o collegare un account su siti partner usando le proprie credenziali ChatGPT, come farebbero con Google o Apple. Annunciato il 2 ago 2026 come beta.
  • Cosa attraversa il confine al sign-in. Tre claim: nome, email, foto profilo. Niente altro, e niente sulla cronologia chat dell'utente.
  • Chi è sul palco per primo. Sei partner di lancio dal mondo dev-tools: Airtable, GitLab, HubSpot, Notion, Supabase, Vercel. Non è una lista casuale — è il gruppo muscolare che permette a una sessione ChatGPT di costruire e deployare software end-to-end.
  • Cosa devono costruire gli sviluppatori. Un flusso standard OAuth 2.1 authorization-code con PKCE (S256) e discovery OIDC — ChatGPT si registra da solo via Dynamic Client Registration al tuo registration_endpoint e chiama il tuo authorization_endpoint / token_endpoint come qualsiasi altro client. Se già supporti OIDC, sei all'80% del lavoro.
  • Il default enterprise che frega. Le organizzazioni che non hanno impostato una policy esplicita sono opt-in di default; gli admin possono spegnere Sign in with ChatGPT a livello di org o limitarlo a un allow-list di app partner.

Perché è più importante di "un altro pulsante di login"​

I pulsanti di login sembrano intercambiabili finché non ti accorgi di chi diventa il provider di identità. Google Sign-in ha normalizzato il pattern in cui un fornitore di produttività possiede anche la tua identità. Sign in with ChatGPT fa lo stesso trucco — ma dal lato assistente del workflow, non dal lato casella email.

Da lì seguono due cose, e vale la pena nominarle:

  1. Il provider di identità è ora il posto dove i tuoi utenti hanno già una sessione attiva con un agente. Quell'agente può, per conto dell'utente, invocare connettori Apps SDK su siti partner (Notion, Vercel, Supabase, ...) con un token che l'utente ha appena approvato. Il pulsante non è solo "fammi accedere"; è "lascia che questo assistente allunghi la mano dentro quello strumento per me".
  2. I partner del lancio sono gli strumenti di cui un agente di coding autonomo ha bisogno. Modello + DB (Supabase) + backend (GitLab / Vercel) + documentazione (Notion) + foglio di calcolo di riferimento (Airtable) + CRM (HubSpot). È la forma di una sessione che inizia in ChatGPT e finisce con qualcosa spedito. È un'anteprima di dove OpenAI si aspetta che vivranno le sessioni Apps SDK.

Se stai costruendo su Claude e stai leggendo pensando "questo non mi tocca" — ti tocca, indirettamente. Qualunque assistente i tuoi utenti usino anche loro, vorrà allungare la mano negli stessi tool B2B che usi tu, con lo stesso layer di login. Capire questo pattern presto è come decidi se accettarlo, rispecchiarlo (Sign in with Claude non è un prodotto pubblico oggi), o girarci intorno con il tuo OIDC.

Cosa attraversa davvero il confine​

Il perimetro dei claim al sign-in è deliberatamente stretto. Quando un utente completa il flusso, il partner riceve:

ClaimIncluso?Note
name✅Il display name dell'utente sul suo account ChatGPT
email✅L'email associata all'account ChatGPT
picture✅URL della foto profilo
Cronologia chat❌Mai condivisa con il partner
Memorie / istruzioni personalizzate❌Mai condivise
Piano (Free / Plus / Pro / Enterprise)❌Non esposto come claim al sign-in
Dati di pagamento❌Non nello scope di questo flusso

Il corollario — la parte che gli utenti tendono a perdersi — è cosa OpenAI impara dal lato partner: in quali app hai fatto sign-in, e quando. È la forma di ogni identità federata: l'IdP vede i tuoi login, il RP vede la tua identità. È lo stesso patto che fai con Google o Apple; sta solo venendo fatto con una nuova controparte la cui ragion d'essere è diversa.

Watch out
  • Sign in with ChatGPT è una federazione di login, non un tunnel di condivisione dati. Il partner riceve claim di identità, non le tue chat — ma OpenAI vede in quali partner accedi.
  • Il default enterprise è opt-in. Se gestisci un'org Enterprise o Team e non hai toccato le impostazioni, i tuoi utenti possono già usarlo su una qualsiasi delle sei app partner oggi.

I sei partner del lancio — leggili come una forma​

L'elenco del lancio è la storia qui. Raggruppati per cosa permettono a una sessione di realizzare:

  • Dati / fogli di calcolo — Airtable
  • Documenti / conoscenza — Notion
  • Codebase / SCM — GitLab
  • Database / backend — Supabase
  • Deploy / hosting — Vercel
  • CRM / dati GTM — HubSpot

Non è "sei early adopter presi a caso". È lo stack operativo di una sessione builder guidata da ChatGPT: pesca un lead da HubSpot, guarda il record in Airtable, scrivi il cambio in Notion, spedisci il codice via GitLab, migra il DB in Supabase, deploya via Vercel. Ognuno di quei passi è un posto in cui i connettori Apps SDK di OpenAI già vogliono stare.

Se il tuo prodotto è adiacente a uno di questi — issue tracker, CRM, low-code, vector store, analytics — assumi che il supporto a Sign in with ChatGPT diventerà una domanda table-stakes dai tuoi buyer enterprise nei prossimi due trimestri.

Cosa deve costruire uno sviluppatore​

La buona notizia: è semplice OAuth 2.1 + OIDC. Se hai già un authorization server che parla OIDC discovery e Dynamic Client Registration, per lo più configuri, non scrivi codice. Ecco la forma che ChatGPT si aspetta.

Gli endpoint che ChatGPT chiama​

Guided walkthrough1 of 6
  1. Esponi /.well-known/openid-configuration (e, se questo è un resource server MCP, /.well-known/oauth-protected-resource che punta a esso). ChatGPT lo legge per trovare i tuoi authorization_endpoint, token_endpoint, registration_endpoint e jwks_uri.

I requisiti non ovvi​

La maggior parte dei team che sbaglia perde una giornata su uno di questi:

  • PKCE è obbligatorio e deve essere S256. Pubblicizza "code_challenge_methods_supported": ["S256"] nel tuo documento di discovery. plain non è accettato.
  • Devi legare l'access token alla resource. Usa il parametro resource e copia il suo valore nel claim aud del token. Se non lo fai, un attacco di audience-confusion è la tua vulnerabilità principale.
  • Client pubblico, niente secret. ChatGPT usa token_endpoint_auth_method: none (o, se preferisci, private_key_jwt contro la JWKS pubblicata di ChatGPT). Non richiedere un client_secret nello scambio del token o il flusso fallisce e basta.
  • Ruota a ogni refresh. Tratta i refresh token come one-time-use, ruotati a ogni scambio. È guidance standard di OAuth 2.1, ed è la differenza tra un refresh token rubato che è fastidioso e uno catastrofico.
  • Gestisci la revoca centrale. Un admin enterprise può revocare Sign in with ChatGPT a livello di org in qualsiasi momento. La tua app deve degradare con grazia — un 401 sul refresh del token non è un bug da mandare in pager; è un segnale per chiedere all'utente di ricollegare o fare fallback al tuo login nativo.

Il documento di discovery minimo​

Abbastanza per far parlare ChatGPT con te (riempi il tuo issuer e i path):

Minimo /.well-known/openid-configuration per Sign in with ChatGPT

{
"issuer": "https://auth.example.com",
"authorization_endpoint": "https://auth.example.com/oauth/authorize",
"token_endpoint": "https://auth.example.com/oauth/token",
"registration_endpoint": "https://auth.example.com/oauth/register",
"jwks_uri": "https://auth.example.com/.well-known/jwks.json",
"response_types_supported": ["code"],
"grant_types_supported": ["authorization_code", "refresh_token"],
"code_challenge_methods_supported": ["S256"],
"token_endpoint_auth_methods_supported": ["none", "private_key_jwt"],
"subject_types_supported": ["public"],
"id_token_signing_alg_values_supported": ["RS256"],
"scopes_supported": ["openid", "email", "profile"]
}

Lo scope che probabilmente vuoi​

Se stai costruendo un'app partner e vuoi accettare Sign in with ChatGPT puramente come segnale di identità — nessun accesso data-plane all'account ChatGPT dell'utente — richiedi solo gli scope OIDC:

Richiesta di autorizzazione solo-identità (nessun accesso data-plane)

GET /oauth/authorize?
response_type=code
&client_id={registered_client_id}
&redirect_uri=https://chatgpt.com/connector/oauth/{callback_id}
&scope=openid+email+profile
&code_challenge={base64url(sha256(verifier))}
&code_challenge_method=S256
&state={csrf_nonce}
&resource=https://api.example.com

La forma dell'URI di redirect (https://chatgpt.com/connector/oauth/{callback_id}) è importante — è quella attraverso cui ChatGPT stesso instrada il ritorno, non una che configuri dal tuo lato.

Controlli enterprise (e il default che ti morderà)​

Per le organizzazioni sui piani Team / Enterprise, gli admin hanno due controlli oggi:

  • Disabilitare Sign in with ChatGPT a livello di org. Spegne il pulsante per tutti nell'org.
  • Limitare a una lista approvata di app partner. Gli utenti possono completare il flusso solo verso i partner nella tua allow-list.

La sfumatura: le org senza una policy esplicita sono opt-in di default — per i sei partner del lancio, tutti i tuoi utenti possono usare il pulsante proprio adesso. Se la tua postura di sicurezza non permette identità federata verso terze parti arbitrarie, devi cambiare il default esplicitamente. È la singola frase che influenza di più i deployment enterprise reali di questo mese.

Come si confronta con Google / Apple / Microsoft sign-in​

DimensioneSign in with ChatGPTGoogleAppleMicrosoft
Claim di identità al sign-innome, email, fotoAmpi (nome, email, foto, più scope opzionali per dati)Nome, opzione email private-relayNome, email, info tenant
Accesso data-plane con la stessa authSì — i connettori Apps SDK possono ricevere i propri scope nella stessa sessioneSì — API Google via OAuth scopedLimitato (Sign in with Apple è principalmente identità)Sì — Graph API via OAuth scoped
Opzione email anonimizzataNo (oggi)NoSì — email private-relayNo
Controlli admin enterpriseDisabilitazione org-wide + allow-list partnerConsole admin Workspace completaGestito da MDMConsole Entra ID completa
Client pubblico + PKCE richiestoSì, S256 obbligatorioOpzionale (raccomandato)SìSì
Sessione cross-app con un agenteSì — è il puntoNoNoNo (Copilot è una storia separata)

Due righe da notare: niente email private-relay (a differenza di Apple, gli utenti non possono nascondere il loro indirizzo reale), e sessione cross-app con un agente (la riga che spiega perché questa cosa esiste in primo luogo).

Quando aggiungerlo — e quando girarci intorno​

Pro tip
  • Aggiungilo se i tuoi buyer sono AI-forward e il tuo prodotto sta dentro le sei categorie adiacenti ai partner (dev tools, dati, docs, CRM, deploy). Il pulsante è un segnale, economico da aggiungere se già supporti OIDC.
  • Aggiungilo se vuoi che la tua app sia raggiungibile da una sessione ChatGPT come connettore Apps SDK. Sign in with ChatGPT è la porta d'ingresso naturale per questo.
  • Giragli intorno se i tuoi utenti sono regolamentati (sanità, finanza, PA) e OpenAI non è nella lista dei sub-processor approvati — l'identità federata implica fiducia sul trattamento dati.
  • Giragli intorno se la differenziazione del tuo prodotto è essere AI-neutrale. Aggiungere il pulsante di un assistente e non degli altri è una dichiarazione di posizionamento, lo volessi o no.

Il pattern pragmatico su cui la maggior parte dei team atterra: spediscilo affiancato a Google, Apple e Microsoft (non al posto di nessuno di loro), limitato ai claim solo-identità, con l'interruttore admin enterprise cablato ai tuoi controlli SSO esistenti.

Modalità di fallimento da progettare​

Prima di mandare in produzione il pulsante, cabla i quattro percorsi di fallimento:

Guided walkthrough1 of 4
  1. Un admin enterprise disabilita Sign in with ChatGPT mentre l'utente ha una sessione live. Il tuo prossimo refresh del token restituisce 401. Non fare logout dell'utente in silenzio — mostra un prompt chiaro 'ricollega il tuo account' con un fallback al login nativo.

Verifica veloce​

Check yourself

0/4
  1. Un utente accede alla tua app con Sign in with ChatGPT. Quale delle seguenti cose riceve la tua app di default?
  2. Stai implementando il token endpoint. ChatGPT non riesce a scambiare il codice di autorizzazione. Qual è la causa più probabile?
  3. Un admin enterprise non ha toccato nessuna impostazione di Sign in with ChatGPT. Qual è la policy effettiva per i suoi utenti oggi?
  4. Quale metodo di code challenge PKCE devi supportare per Sign in with ChatGPT?

Correlato su AILmanac​

Fonti e approfondimenti​