Anmelden mit ChatGPT

Fortgeschritten

Am 2. August 2026 machte OpenAI ChatGPT zu einem Identity Provider. "Anmelden mit ChatGPT" ist jetzt eine öffentliche Beta, angesiedelt in derselben Button-Reihe wie Anmelden mit Google, Apple und Microsoft — und definiert leise neu, wo ein Großteil der B2B-Authentifizierung künftig leben wird. Diese Seite spricht zwei Leser gleichzeitig an: den Nutzer, der wissen will, was tatsächlich die Grenze überschreitet, wenn er auf den Button klickt, und den Entwickler, der entscheiden muss, ob er ihn in seine eigene App einbauen soll (und wenn ja, wie, ohne OpenAI zu einer tragenden Abhängigkeit zu machen).

What you'll learn

Verstehen, was eine Partner-App erhält, wenn sich ein Nutzer mit ChatGPT anmeldet — und was nicht
Die sechs Launch-Day-Partner kennen und wissen, warum sie ausgewählt wurden (es ist ein Signal, kein Zufall)
Den genauen OAuth 2.1 + PKCE + OIDC-Flow durchgehen, den ChatGPT auf deinem Server erwartet
Die Enterprise-Admin-Kontrollen sehen, die bereits verfügbar sind — und den Standard, der die Leute überrascht
Die Fehlermodi kennen, für die man designen muss, bevor man den Button auf seinen Login-Screen setzt

Die 60-Sekunden-Version

Was gestartet ist. Ein plattformübergreifendes Identitätssystem: Nutzer können auf Partnerseiten einen Account mit ihren ChatGPT-Zugangsdaten erstellen oder verknüpfen, genauso wie sie Google oder Apple nutzen würden. Angekündigt am 2. Aug. 2026 als Beta.
Was beim Sign-in die Grenze überschreitet. Drei Claims: Name, E-Mail, Profilbild. Sonst nichts, und nichts über den Chat-Verlauf des Nutzers.
Wer zuerst auf der Bühne steht. Sechs Dev-Tools-Launch-Partner: Airtable, GitLab, HubSpot, Notion, Supabase, Vercel. Das ist keine zufällige Liste — es ist die Muskelgruppe, die einer ChatGPT-Session erlaubt, Software Ende-zu-Ende zu bauen und zu deployen.
Was Entwickler bauen müssen. Ein standardmäßiger OAuth 2.1 Authorization-Code-Flow mit PKCE (S256) und OIDC-Discovery — ChatGPT registriert sich selbst per Dynamic Client Registration an deinem registration_endpoint und ruft deinen authorization_endpoint / token_endpoint auf wie jeder andere Client. Wenn du bereits OIDC ausrollst, bist du zu 80 % am Ziel.
Der Enterprise-Default, der Leute stolpern lässt. Organisationen, die keine explizite Policy gesetzt haben, sind standardmäßig opt-in; Admins können Anmelden mit ChatGPT entweder org-weit ausschalten oder auf eine Allow-Liste von Partner-Apps beschränken.

Login-Buttons wirken austauschbar, bis man merkt, wer zum Identity Provider wird. Google Sign-in normalisierte das Muster, dass ein Productivity-Anbieter auch deine Identität besitzt. Anmelden mit ChatGPT macht denselben Trick — aber von der Assistenten-Seite des Workflows, nicht von der Mailbox-Seite.

Zwei Dinge folgen daraus, und die sind es wert, benannt zu werden:

Der Identity Provider ist jetzt der Ort, wo deine Nutzer bereits eine aktive Session mit einem Agenten haben. Dieser Agent kann im Namen des Nutzers Apps-SDK-Connectors auf Partnerseiten (Notion, Vercel, Supabase, ...) mit einem Token aufrufen, das der Nutzer gerade genehmigt hat. Der Button ist nicht nur "melde mich an"; er ist "lass diesen Assistenten für mich in dieses Tool hineingreifen".
Die Launch-Partner sind die Tools, die ein autonomer Coding-Agent braucht. Modell + DB (Supabase) + Backend (GitLab / Vercel) + Docs (Notion) + Spreadsheet-of-Record (Airtable) + CRM (HubSpot). Das ist die Form einer Session, die in ChatGPT beginnt und mit etwas Ausgeliefertem endet. Es ist eine Vorschau darauf, wo OpenAI erwartet, dass Apps-SDK-Sessions leben.

Wenn du auf Claude baust und dies liest und denkst "das betrifft mich nicht" — es tut es, indirekt. Welcher Assistent auch immer deine Nutzer sonst noch verwenden, er wird in dieselben B2B-Tools hineingreifen wollen wie du, über dieselbe Login-Schicht. Dieses Muster früh zu verstehen ist der Weg, wie du entscheidest, ob du es akzeptierst, spiegelst (Anmelden mit Claude ist heute kein öffentliches Produkt) oder mit deinem eigenen OIDC umgehst.

Was tatsächlich die Grenze überschreitet

Die Claim-Grenze beim Sign-in ist bewusst schmal. Wenn ein Nutzer den Flow abschließt, erhält der Partner:

Claim	Enthalten?	Hinweise
`name`	✅	Der Anzeigename des Nutzers auf seinem ChatGPT-Account
`email`	✅	Die mit dem ChatGPT-Account verknüpfte E-Mail
`picture`	✅	URL des Profilbilds
Chat-Verlauf	❌	Wird nie mit dem Partner geteilt
Memories / Custom Instructions	❌	Wird nie geteilt
Plan-Stufe (Free / Plus / Pro / Enterprise)	❌	Beim Sign-in nicht als Claim exponiert
Zahlungsinformationen	❌	Nicht im Scope dieses Flows

Die Kehrseite — der Teil, den Nutzer gerne übersehen — ist, was OpenAI von der Partnerseite lernt: in welche Apps du dich eingeloggt hast und wann. Das ist die Form jeder föderierten Identität: der IdP sieht deine Logins, der RP sieht deine Identität. Es ist derselbe Deal, den du mit Google oder Apple machst; er wird nur mit einem neuen Gegenüber gemacht, dessen Existenzgrund ein anderer ist.

Watch out

Anmelden mit ChatGPT ist eine Login-Föderation, kein Data-Sharing-Tunnel. Der Partner bekommt Identitäts-Claims, nicht deine Chats — aber OpenAI sieht, bei welchen Partnern du dich einloggst.
Der Enterprise-Default ist Opt-in. Wenn du eine Enterprise- oder Team-Org betreibst und die Einstellungen nicht angefasst hast, können deine Nutzer den Button heute schon auf jeder der sechs Partner-Apps verwenden.

Die sechs Launch-Partner — lies sie als Form

Die Launch-Liste ist die eigentliche Geschichte. Gruppiert danach, was sie einer Session zu leisten erlauben:

Daten / Spreadsheets — Airtable
Docs / Wissen — Notion
Codebase / SCM — GitLab
Datenbank / Backend — Supabase
Deploy / Hosting — Vercel
CRM / GTM-Daten — HubSpot

Das sind nicht "sechs zufällige Early Adopter". Es ist der Operating-Stack einer ChatGPT-getriebenen Builder-Session: einen Lead aus HubSpot ziehen, den Datensatz in Airtable nachschlagen, die Änderung in Notion schreiben, den Code durch GitLab ausliefern, die DB in Supabase migrieren, über Vercel deployen. Jeder dieser Schritte ist ein Ort, an dem die Apps-SDK-Connectors von OpenAI schon jetzt sein wollen.

Wenn dein Produkt an eines dieser angrenzt — Issue Tracker, CRM, Low-Code, Vector Store, Analytics — geh davon aus, dass Anmelden-mit-ChatGPT-Support in den nächsten zwei Quartalen zu einer Table-Stakes-Frage deiner Enterprise-Käufer wird.

Was ein Entwickler bauen muss

Die gute Nachricht: Es ist einfaches OAuth 2.1 + OIDC. Wenn du bereits einen Authorization Server hast, der OIDC-Discovery und Dynamic Client Registration spricht, konfigurierst du meist, statt zu coden. Hier ist die Form, die ChatGPT erwartet.

Die Endpoints, die ChatGPT aufruft

Guided walkthrough1 of 6

Du stellst /.well-known/openid-configuration bereit (und, falls das hier ein MCP-Resource-Server ist, /.well-known/oauth-protected-resource, der darauf zeigt). ChatGPT liest dies, um deinen authorization_endpoint, token_endpoint, registration_endpoint und jwks_uri zu finden.

Die nicht-offensichtlichen Anforderungen

Die meisten Teams, die das falsch machen, verlieren einen Tag an einem dieser Punkte:

PKCE ist Pflicht und muss S256 sein. Wirb "code_challenge_methods_supported": ["S256"] in deinem Discovery-Dokument. plain wird nicht akzeptiert.
Du musst das Access Token an die Resource binden. Nutze den resource-Parameter und kopiere seinen Wert in den aud-Claim des Tokens. Wenn du das nicht tust, ist ein Audience-Confusion-Angriff deine oberste Schwachstelle.
Public Client, kein Secret. ChatGPT verwendet token_endpoint_auth_method: none (oder, wenn du willst, private_key_jwt gegen ChatGPTs veröffentlichte JWKS). Verlange kein client_secret beim Token-Austausch, sonst schlägt der Flow einfach fehl.
Rotiere bei jedem Refresh. Behandle Refresh Tokens als Einweg-Tokens, rotiert bei jedem Austausch. Das ist Standard-OAuth-2.1-Guidance und der Unterschied zwischen einem gestohlenen Refresh Token, das nur lästig ist, und einem, das katastrophal ist.
Handhabe zentrale Revocation. Ein Enterprise-Admin kann Anmelden mit ChatGPT jederzeit org-weit widerrufen. Deine App muss graceful degradieren — ein 401 beim Token-Refresh ist kein Bug für Pager-Alerts; er ist ein Signal, den Nutzer aufzufordern, sich neu zu verknüpfen oder auf dein eigenes Login zurückzufallen.

Das minimale Discovery-Dokument

Genug, damit ChatGPT mit dir spricht (fülle deinen Issuer und Pfade aus):

Minimum /.well-known/openid-configuration for 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"]
}

Der Scope, den du wahrscheinlich willst

Wenn du eine Partner-App baust und Anmelden mit ChatGPT rein als Identitätssignal akzeptieren willst — kein Data-Plane-Zugriff auf den ChatGPT-Account des Nutzers — verlange nur die OIDC-Scopes:

Identity-only authorization request (no data-plane access)

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

Die Form der Redirect-URI (https://chatgpt.com/connector/oauth/{callback_id}) ist wichtig — sie ist die, durch die ChatGPT selbst zurückroutet, nicht die, die du auf deiner Seite konfigurierst.

Enterprise-Kontrollen (und der Default, der dich beißen wird)

Für Organisationen auf Team- / Enterprise-Plänen bekommen Admins heute zwei Kontrollen:

Anmelden mit ChatGPT org-weit deaktivieren. Schaltet den Button für alle in der Org aus.
Auf eine genehmigte Liste von Partner-Apps beschränken. Nutzer können den Flow nur in Partner auf deiner Allow-Liste abschließen.

Die Nuance: Orgs ohne explizite Policy sind standardmäßig opt-in — für die sechs Launch-Partner können alle deine Nutzer den Button gerade jetzt verwenden. Wenn deine Security-Haltung föderierte Identität in beliebige Dritte nicht erlaubt, musst du den Default explizit ändern. Das ist der einzelne Satz, der die realen Enterprise-Deployments diesen Monat am meisten betrifft.

Dimension	Anmelden mit ChatGPT	Google	Apple	Microsoft
Identitäts-Claims beim Sign-in	Name, E-Mail, Bild	Umfangreich (Name, E-Mail, Bild, plus optionale Scopes für Daten)	Name, Private-Relay-E-Mail-Option	Name, E-Mail, Tenant-Info
Data-Plane-Zugriff über dieselbe Auth	Ja — Apps-SDK-Connectors können in derselben Session eigene Scopes erhalten	Ja — Google APIs über gescopte OAuth	Begrenzt (Sign in with Apple ist primär Identität)	Ja — Graph API über gescopte OAuth
Anonymisierte E-Mail-Option	Nein (heute)	Nein	Ja — Private-Relay-E-Mails	Nein
Enterprise-Admin-Kontrollen	Org-weites Disable + Partner-Allow-Liste	Volle Workspace-Admin-Konsole	MDM-verwaltet	Volle Entra-ID-Konsole
Public Client + PKCE erforderlich	Ja, S256 Pflicht	Optional (empfohlen)	Ja	Ja
Cross-App-Session mit einem Agenten	Ja — das ist der Sinn	Nein	Nein	Nein (Copilot ist eine separate Geschichte)

Zwei Zeilen zum Beachten: keine Private-Relay-E-Mail (anders als Apple, Nutzer können ihre echte Adresse nicht verbergen), und Cross-App-Session mit einem Agenten (die Zeile, die erklärt, warum dies überhaupt existiert).

Wann einbauen — und wann drumherum routen

Pro tip

Baue es ein, wenn deine Käufer AI-forward sind und dein Produkt in den sechs Partner-nahen Kategorien sitzt (Dev-Tools, Daten, Docs, CRM, Deploy). Der Button ist ein Signal, billig hinzuzufügen, wenn du bereits OIDC ausrollst.
Baue es ein, wenn du willst, dass deine App aus einer ChatGPT-Session als Apps-SDK-Connector erreichbar ist. Anmelden mit ChatGPT ist die natürliche Vordertür dafür.
Route drumherum, wenn deine Nutzer reguliert sind (Gesundheit, Finanzen, Behörden) und OpenAI nicht auf der genehmigten Sub-Processor-Liste steht — föderierte Identität impliziert Datenverarbeitungs-Vertrauen.
Route drumherum, wenn die Differenzierung deines Produkts AI-Neutralität ist. Den Button eines Assistenten hinzuzufügen und den anderer nicht, ist ein Positionierungsstatement, egal ob du es so meintest oder nicht.

Das pragmatische Muster, auf dem die meisten Teams landen: rolle es neben Google, Apple und Microsoft aus (nicht anstelle irgendeines davon), begrenzt auf Identity-only-Claims, mit dem Enterprise-Admin-Toggle an deine bestehenden SSO-Kontrollen angebunden.

Fehlermodi, für die man designen muss

Bevor du den Button live schaltest, verdrahte die vier Fehler-Pfade:

Guided walkthrough1 of 4

Ein Enterprise-Admin deaktiviert Anmelden mit ChatGPT, während der Nutzer eine aktive Session hat. Dein nächster Token-Refresh gibt 401 zurück. Logge den Nutzer nicht still aus — zeige einen klaren 'Verknüpfe deinen Account neu'-Prompt mit einem Fallback auf natives Login.

Schneller Check

Check yourself

0/4

Ein Nutzer meldet sich mit Anmelden mit ChatGPT in deiner App an. Welches der folgenden erhält deine App standardmäßig?
Du implementierst den Token-Endpoint. ChatGPT scheitert beim Austausch des Authorization-Codes. Was ist die wahrscheinlichste Ursache?
Ein Enterprise-Admin hat keine Anmelden-mit-ChatGPT-Einstellungen angefasst. Was ist heute die effektive Policy für seine Nutzer?
Welche PKCE-Code-Challenge-Methode musst du für Anmelden mit ChatGPT unterstützen?

Quellen & Weiterführendes

OpenAI — Introducing Sign in with ChatGPT
OpenAI Developers — Apps SDK: Authentication
OpenAI — ChatGPT release notes
OpenAI — GPT Action authentication
Stytch — Guide to authentication and user consent in the OpenAI Apps SDK
IETF — OAuth 2.1 draft
OpenID Foundation — OpenID Connect Core 1.0

Die 60-Sekunden-Version​

Warum das eine größere Sache ist als "noch ein Login-Button"​

Was tatsächlich die Grenze überschreitet​

Die sechs Launch-Partner — lies sie als Form​

Was ein Entwickler bauen muss​

Die Endpoints, die ChatGPT aufruft​

Die nicht-offensichtlichen Anforderungen​

Das minimale Discovery-Dokument​

Minimum /.well-known/openid-configuration for Sign in with ChatGPT

Der Scope, den du wahrscheinlich willst​

Identity-only authorization request (no data-plane access)

Enterprise-Kontrollen (und der Default, der dich beißen wird)​

Wie es sich mit Google / Apple / Microsoft Sign-in vergleicht​

Wann einbauen — und wann drumherum routen​

Fehlermodi, für die man designen muss​

Schneller Check​