Skip to main content

Sign in with ChatGPT

Intermediate

On 2 August 2026 OpenAI turned ChatGPT into an identity provider. "Sign in with ChatGPT" is now a public beta, sitting on the same button rack as Sign in with Google, Apple and Microsoft โ€” and quietly re-drawing where a lot of B2B auth is going to live. This page is for two readers at once: the user who wants to know what actually crosses the line if they click the button, and the developer who has to decide whether to add it to their own app (and if so, how, without making OpenAI a load-bearing dependency).

What you'll learn
  • Understand what a partner app receives when a user signs in with ChatGPT โ€” and what it doesn't
  • Know the six launch-day partners and why they were picked (it's a signal, not a coincidence)
  • Walk the exact OAuth 2.1 + PKCE + OIDC flow that ChatGPT expects on your server
  • See the enterprise admin controls that already ship โ€” and the default that surprises people
  • Know the failure modes to design for before you put the button on your login screen

The 60-second versionโ€‹

  • What launched. A cross-platform identity system: users can create or link an account on partner sites using their ChatGPT credentials, the same way they'd use Google or Apple. Announced 2 Aug 2026 as a beta.
  • What crosses the line at sign-in. Three claims: name, email, profile picture. Nothing else, and nothing about the user's chat history.
  • Who's on stage first. Six developer-tools launch partners: Airtable, GitLab, HubSpot, Notion, Supabase, Vercel. That's not a random list โ€” it's the muscle group that lets a ChatGPT session build and deploy software end-to-end.
  • What developers have to build. A standard OAuth 2.1 authorization-code flow with PKCE (S256) and OIDC discovery โ€” ChatGPT registers itself via Dynamic Client Registration at your registration_endpoint and calls your authorization_endpoint / token_endpoint like any other client. If you already ship OIDC, you're 80 % of the way there.
  • The enterprise default that trips people up. Organisations that haven't set an explicit policy are opted in by default; admins can either turn Sign in with ChatGPT off org-wide or restrict it to an allow-list of partner apps.

Why this is a bigger deal than "another login button"โ€‹

Login buttons look interchangeable until you notice who the identity provider becomes. Google Sign-in normalised the pattern where a productivity vendor also owns your identity. Sign in with ChatGPT does the same trick โ€” but from the assistant side of the workflow, not the mailbox side.

Two things follow from that, and they're worth naming:

  1. The identity provider is now the place your users already have an active session with an agent. That agent can, on the user's behalf, invoke Apps SDK connectors on partner sites (Notion, Vercel, Supabase, ...) with a token that the user just approved. The button isn't only "log me in"; it's "let this assistant reach across into that tool for me".
  2. The launch partners are the tools an autonomous coding agent needs. Model + DB (Supabase) + backend (GitLab / Vercel) + docs (Notion) + spreadsheet-of-record (Airtable) + CRM (HubSpot). That's the shape of a session that starts in ChatGPT and finishes with something shipped. It's a preview of where OpenAI expects Apps SDK sessions to live.

If you're building on Claude and reading this thinking "this doesn't affect me" โ€” it does, indirectly. Whichever assistant your users happen to also use is going to want to reach into the same B2B tools you do, using the same login layer. Understanding this pattern early is how you decide whether to accept it, mirror it (Sign in with Claude is not a public product today), or route around it with your own OIDC.

What actually crosses the lineโ€‹

The claim boundary at sign-in is deliberately narrow. When a user completes the flow, the partner receives:

ClaimIncluded?Notes
nameโœ…The user's display name on their ChatGPT account
emailโœ…The email associated with the ChatGPT account
pictureโœ…Profile picture URL
Chat historyโŒNever shared with the partner
Memories / custom instructionsโŒNever shared
Plan tier (Free / Plus / Pro / Enterprise)โŒNot exposed as a claim at sign-in
Payment infoโŒNot in scope for this flow

The corollary โ€” the part users tend to miss โ€” is what OpenAI learns from the partner side: which apps you signed into, and when. That's the shape of any federated identity: the IdP sees your logins, the RP sees your identity. It's the same trade you make with Google or Apple; it's just being made with a new counterparty whose reason for existing is different.

Watch out
  • Sign in with ChatGPT is a login federation, not a data-sharing tunnel. The partner gets identity claims, not your chats โ€” but OpenAI does see which partners you sign into.
  • The enterprise default is opt-in. If you run an Enterprise or Team org and haven't touched settings, your users can already use it on any of the six partner apps today.

The six launch partners โ€” read them as a shapeโ€‹

The launch roster is the story here. Grouped by what they let a session accomplish:

  • Data / spreadsheets โ€” Airtable
  • Docs / knowledge โ€” Notion
  • Codebase / SCM โ€” GitLab
  • Database / backend โ€” Supabase
  • Deploy / hosting โ€” Vercel
  • CRM / GTM data โ€” HubSpot

This is not "a random six early adopters." It's the operating stack of a ChatGPT-driven builder session: pull a lead from HubSpot, look up the record in Airtable, write the change in Notion, ship the code through GitLab, migrate the DB in Supabase, deploy through Vercel. Every one of those steps is a place OpenAI's Apps SDK connectors already want to be.

If your product is adjacent to any of these โ€” issue tracker, CRM, low-code, vector store, analytics โ€” assume Sign in with ChatGPT support becomes a table-stakes question from your enterprise buyers over the next two quarters.

What a developer has to buildโ€‹

The good news: it's plain OAuth 2.1 + OIDC. If you already have an authorization server that speaks OIDC discovery and Dynamic Client Registration, you mostly configure, not code. Here's the shape ChatGPT expects.

The endpoints ChatGPT callsโ€‹

Guided walkthrough1 of 6
  1. You expose /.well-known/openid-configuration (and, if this is an MCP resource server, /.well-known/oauth-protected-resource pointing at it). ChatGPT reads this to find your authorization_endpoint, token_endpoint, registration_endpoint and jwks_uri.

The non-obvious requirementsโ€‹

Most teams that get this wrong lose a day to one of these:

  • PKCE is mandatory and must be S256. Advertise "code_challenge_methods_supported": ["S256"] in your discovery document. plain is not accepted.
  • You must bind the access token to the resource. Use the resource parameter and copy its value into the token's aud claim. If you don't, an audience-confusion attack is your top vulnerability.
  • Public client, no secret. ChatGPT uses token_endpoint_auth_method: none (or, if you prefer, private_key_jwt against ChatGPT's published JWKS). Don't require a client_secret in the token exchange or the flow just fails.
  • Rotate at every refresh. Treat refresh tokens as one-time-use, rotated on every exchange. This is standard OAuth 2.1 guidance, and it's the difference between a stolen refresh token being annoying and being catastrophic.
  • Handle central revocation. An enterprise admin can revoke Sign in with ChatGPT org-wide at any time. Your app has to degrade gracefully โ€” a 401 on token refresh is not a bug to page on; it's a signal to prompt the user to re-link or fall back to your own login.

The bare-minimum discovery documentโ€‹

Enough to make ChatGPT talk to you (fill in your issuer and paths):

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

The scope you probably wantโ€‹

If you're building a partner app and want to accept Sign in with ChatGPT purely as an identity signal โ€” no data-plane access to the user's ChatGPT account โ€” request only the 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

The redirect URI shape (https://chatgpt.com/connector/oauth/{callback_id}) is important โ€” it's the one ChatGPT itself routes back through, not one you configure on your side.

Enterprise controls (and the default that will bite you)โ€‹

For organisations on Team / Enterprise plans, admins get two controls today:

  • Disable Sign in with ChatGPT org-wide. Turns the button off for everyone in the org.
  • Restrict to an approved list of partner apps. Users can only complete the flow into partners on your allow-list.

The nuance: orgs without an explicit policy are opted in by default โ€” for the six launch partners, all your users can use the button right now. If your security posture doesn't allow federated identity into arbitrary third parties, you have to change the default explicitly. This is the single sentence that most affects real enterprise deployments this month.

How it compares to Google / Apple / Microsoft sign-inโ€‹

DimensionSign in with ChatGPTGoogleAppleMicrosoft
Identity claims at sign-inname, email, pictureBroad (name, email, picture, plus optional scopes for data)Name, private-relay email optionName, email, tenant info
Data-plane access via the same authYes โ€” Apps SDK connectors can be granted their own scopes in the same sessionYes โ€” Google APIs via scoped OAuthLimited (Sign in with Apple is primarily identity)Yes โ€” Graph API via scoped OAuth
Anonymised email optionNo (today)NoYes โ€” private-relay emailsNo
Enterprise admin controlsOrg-wide disable + partner allow-listFull Workspace admin consoleMDM-managedFull Entra ID console
Public client + PKCE requiredYes, S256 mandatoryOptional (recommended)YesYes
Cross-app session with an agentYes โ€” this is the pointNoNoNo (Copilot is a separate story)

Two rows to notice: no private-relay email (unlike Apple, users can't hide their real address), and cross-app session with an agent (the row that explains why this exists in the first place).

When to add it โ€” and when to route aroundโ€‹

Pro tip
  • Add it if your buyers are AI-forward and your product sits inside the six partner-adjacent categories (dev tools, data, docs, CRM, deploy). The button is a signal, cheap to add if you already ship OIDC.
  • Add it if you want your app reachable from a ChatGPT session as an Apps SDK connector. Sign in with ChatGPT is the natural front door for that.
  • Route around it if your users are regulated (health, finance, government) and OpenAI is not on the approved sub-processor list โ€” federated identity implies data-processing trust.
  • Route around it if your product's differentiation is being AI-neutral. Adding one assistant's button and not others is a positioning statement whether you meant it or not.

The pragmatic pattern most teams land on: ship it alongside Google, Apple, and Microsoft (not instead of any of them), scoped to identity-only claims, with the enterprise admin toggle wired to your existing SSO controls.

Failure modes to design forโ€‹

Before you push the button live, wire the four failure paths:

Guided walkthrough1 of 4
  1. An enterprise admin disables Sign in with ChatGPT while the user has a live session. Your next token refresh returns 401. Do not log the user out silently โ€” surface a clear 're-link your account' prompt with a fallback to native login.

Quick checkโ€‹

Check yourself

0/4
  1. A user signs into your app with Sign in with ChatGPT. Which of the following does your app receive by default?
  2. You're implementing the token endpoint. ChatGPT is failing to exchange the authorization code. Which is the most likely cause?
  3. An enterprise admin has not touched any Sign in with ChatGPT settings. What is the effective policy for their users today?
  4. Which PKCE code challenge method must you support for Sign in with ChatGPT?

Sources & further readingโ€‹