ChatGPT로 로그인
2026년 8월 2일, OpenAI는 ChatGPT를 아이덴티티 프로바이더로 전환했습니다. "Sign in with ChatGPT"는 이제 퍼블릭 베타로, Google, Apple, Microsoft 로그인과 같은 버튼 랙에 나란히 자리 잡고 있으며 — 많은 B2B 인증이 앞으로 어디에 자리 잡을지를 조용히 재편하고 있습니다. 이 페이지는 두 종류의 독자를 동시에 겨냥합니다. 버튼을 클릭하면 실제로 무엇이 넘어가는지 알고 싶은 사용자, 그리고 자신의 앱에 이를 추가할지 결정해야 하는 (그리고 추가한다면 OpenAI를 부하 지지 의존성으로 만들지 않으면서 어떻게 할지 결정해야 하는) 개발자입니다.
- 사용자가 ChatGPT로 로그인할 때 파트너 앱이 무엇을 받는지 — 그리고 무엇을 받지 못하는지 이해합니다
- 출시일 6개 파트너와 그들이 선정된 이유를 파악합니다 (이는 우연이 아니라 신호입니다)
- ChatGPT가 서버에서 기대하는 정확한 OAuth 2.1 + PKCE + OIDC 플로우를 살펴봅니다
- 이미 제공되는 엔터프라이즈 관리자 제어 항목 — 그리고 사람들을 놀라게 하는 기본값을 확인합니다
- 로그인 화면에 버튼을 넣기 전에 설계해야 할 실패 모드를 파악합니다
60초 요약
- 무엇이 출시되었나. 크로스 플랫폼 아이덴티티 시스템: 사용자는 Google이나 Apple을 사용하는 것과 같은 방식으로 ChatGPT 자격 증명을 사용해 파트너 사이트에서 계정을 만들거나 연결할 수 있습니다. 2026년 8월 2일 베타로 발표되었습니다.
- 로그인 시 어떤 정보가 넘어가나. 세 가지 클레임: 이름, 이메일, 프로필 사진. 그 외에는 아무것도, 그리고 사용자의 채팅 이력에 관한 것은 아무것도 없습니다.
- 첫 무대에는 누가 올랐나. 6개의 개발자 도구 출시 파트너: Airtable, GitLab, HubSpot, Notion, Supabase, Vercel. 이는 임의의 목록이 아니라 — ChatGPT 세션이 소프트웨어를 엔드-투-엔드로 빌드하고 배포할 수 있게 해주는 근육 그룹입니다.
- 개발자가 무엇을 만들어야 하나. PKCE (S256)와 OIDC 디스커버리를 갖춘 표준 OAuth 2.1 authorization-code 플로우 — ChatGPT는 여러분의
registration_endpoint에서 Dynamic Client Registration을 통해 자신을 등록하고, 다른 클라이언트와 마찬가지로 여러분의authorization_endpoint/token_endpoint를 호출합니다. 이미 OIDC를 제공한다면 80 % 이상 도달한 셈입니다. - 사람들을 걸려 넘어지게 하는 엔터프라이즈 기본값. 명시적 정책을 설정하지 않은 조직은 기본적으로 옵트인 상태입니다. 관리자는 조직 전체에서 Sign in with ChatGPT를 끄거나 파트너 앱의 허용 목록으로 제한할 수 있습니다.
왜 이것이 "또 하나의 로그인 버튼"보다 큰 사건인가
로그인 버튼은 아이덴티티 프로바이더가 누가 되는지 알아차리기 전까지는 서로 바꿔 쓸 수 있는 것처럼 보입니다. Google 로그인은 생산성 벤더가 아이덴티티도 소유하는 패턴을 정상화했습니다. Sign in with ChatGPT는 같은 트릭을 사용하지만 — 메일함이 아니라 워크플로우의 어시스턴트 쪽에서 그렇게 합니다.
여기서 두 가지가 따라 나오며, 이를 명명할 가치가 있습니다:
- 아이덴티티 프로바이더가 이제 사용자가 이미 에이전트와 활성 세션을 가진 곳이 되었습니다. 그 에이전트는 사용자를 대신하여, 방금 사용자가 승인한 토큰으로 파트너 사이트(Notion, Vercel, Supabase, ...)의 Apps SDK 커넥터를 호출할 수 있습니다. 이 버튼은 단순히 "로그인시켜 줘"가 아니라, "이 어시스턴트가 나를 대신해 저 도구로 손을 뻗을 수 있게 해줘"입니다.
- 출시 파트너들은 자율 코딩 에이전트가 필요로 하는 도구입니다. 모델 + DB (Supabase) + 백엔드 (GitLab / Vercel) + 문서 (Notion) + 기록용 스프레드시트 (Airtable) + CRM (HubSpot). 이것이 ChatGPT에서 시작되어 무언가 배포된 것으로 끝나는 세션의 모습입니다. OpenAI가 Apps SDK 세션이 어디에 자리 잡을 것으로 예상하는지를 미리 보여주는 것입니다.
Claude 위에서 빌드하면서 이 글을 읽으며 "이건 나와 상관없어"라고 생각하고 있다면 — 간접적으로 상관있습니다. 여러분의 사용자가 함께 사용하는 어떤 어시스턴트든 여러분과 같은 B2B 도구로 손을 뻗고 싶어할 것이고, 같은 로그인 계층을 사용할 것입니다. 이 패턴을 일찍 이해하는 것이 이를 수용할지, 미러링할지 (Sign in with Claude는 오늘날 공개 제품이 아닙니다), 아니면 자체 OIDC로 우회할지 결정하는 방법입니다.
실제로 넘어가는 것은 무엇인가
로그인 시 클레임 경계는 의도적으로 좁습니다. 사용자가 플로우를 완료하면 파트너는 다음을 받습니다:
| 클레임 | 포함? | 비고 |
|---|---|---|
name | ✅ | ChatGPT 계정의 사용자 표시 이름 |
email | ✅ | ChatGPT 계정과 연결된 이메일 |
picture | ✅ | 프로필 사진 URL |
| 채팅 이력 | ❌ | 절대 파트너와 공유되지 않음 |
| 메모리 / 커스텀 인스트럭션 | ❌ | 절대 공유되지 않음 |
| 요금제 등급 (Free / Plus / Pro / Enterprise) | ❌ | 로그인 시 클레임으로 노출되지 않음 |
| 결제 정보 | ❌ | 이 플로우의 범위 밖 |
당연한 귀결로 — 사용자가 놓치기 쉬운 부분은 — OpenAI가 파트너 쪽에서 무엇을 학습하는가입니다: 어떤 앱에 로그인했는지, 언제 했는지. 이것이 모든 페더레이션 아이덴티티의 형태입니다: IdP는 여러분의 로그인을 보고, RP는 여러분의 아이덴티티를 봅니다. Google이나 Apple과 하는 것과 같은 거래입니다. 다만 존재 이유가 다른 새로운 상대방과 그 거래를 하는 것뿐입니다.
- Sign in with ChatGPT는 데이터 공유 터널이 아니라 로그인 페더레이션입니다. 파트너는 아이덴티티 클레임을 받고 여러분의 채팅은 받지 않지만 — OpenAI는 여러분이 어떤 파트너에 로그인하는지 봅니다.
- 엔터프라이즈 기본값은 옵트인입니다. Enterprise나 Team 조직을 운영하고 있고 설정을 건드리지 않았다면, 여러분의 사용자는 오늘 이미 6개 파트너 앱 어디에서든 이를 사용할 수 있습니다.
6개의 출시 파트너 — 하나의 형태로 읽으세요
출시 명단이 여기서의 이야기입니다. 세션이 무엇을 달성할 수 있는지에 따라 그룹화하면:
- 데이터 / 스프레드시트 — Airtable
- 문서 / 지식 — Notion
- 코드베이스 / SCM — GitLab
- 데이터베이스 / 백엔드 — Supabase
- 배포 / 호스팅 — Vercel
- CRM / GTM 데이터 — HubSpot
이는 "임의의 얼리 어답터 6개"가 아닙니다. ChatGPT 주도 빌더 세션의 운영 스택입니다: HubSpot에서 리드를 가져오고, Airtable에서 레코드를 조회하고, Notion에 변경 사항을 기록하고, GitLab을 통해 코드를 배포하고, Supabase에서 DB를 마이그레이션하고, Vercel을 통해 배포합니다. 이 모든 단계는 OpenAI의 Apps SDK 커넥터가 이미 자리 잡고 싶어하는 위치입니다.
여러분의 제품이 이 중 어떤 것과 인접해 있다면 — 이슈 트래커, CRM, 로우 코드, 벡터 스토어, 애널리틱스 — 향후 두 분기 동안 엔터프라이즈 구매자로부터 Sign in with ChatGPT 지원이 필수 요건 질문이 될 것이라고 가정하세요.
개발자가 만들어야 할 것
좋은 소식: 이는 평범한 OAuth 2.1 + OIDC입니다. OIDC 디스커버리와 Dynamic Client Registration을 지원하는 인증 서버가 이미 있다면, 대부분 코딩이 아니라 구성만 하면 됩니다. ChatGPT가 기대하는 형태는 다음과 같습니다.
ChatGPT가 호출하는 엔드포인트
- 여러분은 /.well-known/openid-configuration을 노출합니다 (그리고 MCP 리소스 서버라면 그것을 가리키는 /.well-known/oauth-protected-resource도). ChatGPT는 이를 읽어 여러분의 authorization_endpoint, token_endpoint, registration_endpoint, jwks_uri를 찾습니다.
- ChatGPT는 여러분의 registration_endpoint에 POST하여 자신을 퍼블릭 클라이언트로 등록합니다. 여러분은 반환된 client_id를 저장합니다. 공유 시크릿은 발급되지 않으며 — PKCE가 리플레이 방지 메커니즘입니다.
- ChatGPT는 response_type=code, code_challenge, code_challenge_method=S256, 요청된 스코프, 그리고 여러분의 API를 식별하는 resource 파라미터와 함께 사용자를 여러분의 authorization_endpoint로 리디렉션합니다.
- 동의 화면은 ChatGPT가 무엇을 요청하는지 사용자에게 보여줍니다. 요청된 스코프를 있는 그대로 표시하고, 친절한 요약 뒤에 숨기지 마세요. 이것이 사용자가 그것들을 볼 유일한 기회입니다.
- ChatGPT는 code와 code_verifier를 여러분의 token_endpoint에 POST합니다. 여러분은 aud가 resource 파라미터와 일치하는 액세스 토큰을 발급하고, (OIDC 스코프를 지원한다면) id_token을 발급합니다.
- 만료 시 ChatGPT는 플로우를 다시 실행합니다. id_token을 발급했다면 ChatGPT는 id_token_hint를 통해 이를 다시 전달하여 사용자가 다시 로그인하라는 프롬프트를 받지 않도록 합니다 — 그들은 증분 동의만 봅니다.
자명하지 않은 요구사항
이것을 잘못하는 대부분의 팀은 다음 중 하나로 하루를 잃습니다:
- PKCE는 필수이며
S256이어야 합니다. 디스커버리 문서에서"code_challenge_methods_supported": ["S256"]을 광고하세요.plain은 허용되지 않습니다. - 액세스 토큰을 리소스에 바인딩해야 합니다.
resource파라미터를 사용하고 그 값을 토큰의aud클레임에 복사하세요. 그렇지 않으면 audience-confusion 공격이 여러분의 최상위 취약점이 됩니다. - 퍼블릭 클라이언트, 시크릿 없음. ChatGPT는
token_endpoint_auth_method: none을 사용합니다 (또는 원한다면 ChatGPT의 게시된 JWKS에 대해private_key_jwt를 사용합니다). 토큰 교환에서client_secret을 요구하지 마세요. 그렇지 않으면 플로우가 그냥 실패합니다. - 리프레시할 때마다 로테이션하세요. 리프레시 토큰은 일회용으로, 교환할 때마다 로테이션되는 것으로 취급하세요. 이는 표준 OAuth 2.1 지침이며, 훔친 리프레시 토큰이 성가신 것과 재앙적인 것의 차이입니다.
- 중앙 취소를 처리하세요. 엔터프라이즈 관리자는 언제든지 조직 전체에서 Sign in with ChatGPT를 취소할 수 있습니다. 여러분의 앱은 우아하게 성능 저하되어야 합니다 — 토큰 리프레시에서 401은 페이지로 알릴 버그가 아니라, 사용자에게 다시 연결하거나 여러분의 자체 로그인으로 폴백하도록 유도하라는 신호입니다.
최소한의 디스커버리 문서
ChatGPT가 여러분과 통신하기에 충분한 정도 (issuer와 경로를 채워 넣으세요):
Sign in with ChatGPT를 위한 최소 /.well-known/openid-configuration
{
"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"]
}여러분이 아마 원할 스코프
파트너 앱을 만들고 있고 Sign in with ChatGPT를 순수하게 아이덴티티 신호로만 받아들이고 싶다면 — 사용자의 ChatGPT 계정에 대한 데이터 플레인 액세스 없이 — OIDC 스코프만 요청하세요:
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리디렉트 URI 형태 (https://chatgpt.com/connector/oauth/{callback_id})가 중요합니다 — 이는 여러분 쪽에서 구성하는 것이 아니라 ChatGPT 자체가 되돌아가는 경로입니다.
엔터프라이즈 제어 (그리고 여러분을 물게 될 기본값)
Team / Enterprise 요금제의 조직의 경우, 관리자는 오늘 두 가지 제어를 받습니다:
- 조직 전체에서 Sign in with ChatGPT 비활성화. 조직의 모든 사람에 대해 버튼을 끕니다.
- 승인된 파트너 앱 목록으로 제한. 사용자는 여러분의 허용 목록에 있는 파트너에 대해서만 플로우를 완료할 수 있습니다.
미묘한 점: 명시적 정책이 없는 조직은 기본적으로 옵트인되어 있습니다 — 6개의 출시 파트너에 대해 모든 사용자가 지금 당장 버튼을 사용할 수 있습니다. 여러분의 보안 태세가 임의의 서드파티로의 페더레이션 아이덴티티를 허용하지 않는다면, 명시적으로 기본값을 변경해야 합니다. 이것이 이번 달 실제 엔터프라이즈 배포에 가장 영향을 미치는 단 한 문장입니다.
Google / Apple / Microsoft 로그인과 비교하면 어떤가
| 차원 | Sign in with ChatGPT | Apple | Microsoft | |
|---|---|---|---|---|
| 로그인 시 아이덴티티 클레임 | 이름, 이메일, 사진 | 광범위 (이름, 이메일, 사진, 데이터용 옵션 스코프) | 이름, 개인 릴레이 이메일 옵션 | 이름, 이메일, 테넌트 정보 |
| 동일 인증을 통한 데이터 플레인 액세스 | 예 — Apps SDK 커넥터가 같은 세션에서 자체 스코프를 부여받을 수 있음 | 예 — 스코프 있는 OAuth를 통한 Google API | 제한적 (Sign in with Apple은 주로 아이덴티티용) | 예 — 스코프 있는 OAuth를 통한 Graph API |
| 익명화 이메일 옵션 | 없음 (오늘) | 없음 | 있음 — 개인 릴레이 이메일 | 없음 |
| 엔터프라이즈 관리자 제어 | 조직 전체 비활성화 + 파트너 허용 목록 | 전체 Workspace 관리 콘솔 | MDM 관리 | 전체 Entra ID 콘솔 |
| 퍼블릭 클라이언트 + PKCE 필수 | 예, S256 필수 | 선택 (권장) | 예 | 예 |
| 에이전트와의 크로스 앱 세션 | 예 — 이것이 요점 | 아니오 | 아니오 | 아니오 (Copilot은 별개 이야기) |
두 행을 주목하세요: 개인 릴레이 이메일 없음 (Apple과 달리, 사용자는 실제 주소를 숨길 수 없음), 그리고 에이전트와의 크로스 앱 세션 (애초에 이것이 존재하는 이유를 설명하는 행).
언제 추가해야 하나 — 그리고 언제 우회해야 하나
- 구매자가 AI 지향적이고 여러분의 제품이 6개의 파트너 인접 카테고리 (개발자 도구, 데이터, 문서, CRM, 배포) 내에 있다면 추가하세요. 버튼은 신호이며, 이미 OIDC를 제공한다면 추가하는 비용은 낮습니다.
- 여러분의 앱이 ChatGPT 세션에서 Apps SDK 커넥터로 도달 가능하기를 원한다면 추가하세요. Sign in with ChatGPT는 그것을 위한 자연스러운 정문입니다.
- 여러분의 사용자가 규제 대상 (건강, 금융, 정부)이고 OpenAI가 승인된 서브프로세서 목록에 없다면 우회하세요 — 페더레이션 아이덴티티는 데이터 처리 신뢰를 함축합니다.
- 여러분의 제품 차별화가 AI 중립성이라면 우회하세요. 한 어시스턴트의 버튼을 추가하고 다른 것들을 추가하지 않는 것은 의도했든 아니든 포지셔닝 성명입니다.
대부분의 팀이 도달하는 실용적 패턴: Google, Apple, Microsoft와 함께 (그 중 어느 것을 대신하지 않고) 배포하고, 아이덴티티 전용 클레임으로 스코프를 지정하며, 엔터프라이즈 관리자 토글을 기존 SSO 제어에 연결합니다.
설계해야 할 실패 모드
버튼을 라이브로 푸시하기 전에 네 가지 실패 경로를 연결하세요:
- 사용자가 활성 세션을 가지고 있는 동안 엔터프라이즈 관리자가 Sign in with ChatGPT를 비활성화합니다. 다음 토큰 리프레시는 401을 반환합니다. 사용자를 조용히 로그아웃시키지 마세요 — 네이티브 로그인으로의 폴백과 함께 명확한 '계정 다시 연결' 프롬프트를 표시하세요.
- 사용자는 여전히 여러분의 앱에서 유효한 세션을 가지고 있지만 ChatGPT 연결 이메일은 이제 휴면 상태입니다. 그들이 기존 계정에 비밀번호 / 패스키를 첨부할 수 있게 하여 계정을 고아로 만들지 마세요.
- 관리자가 허용 목록에서 여러분의 앱을 제거합니다. 중앙 취소와 동일한 처리. 관리자가 감사할 수 있도록 이유를 로깅하는 지원 대면 엔드포인트를 제공하세요.
- 여러분의 로그인 화면은 ChatGPT의 OIDC 디스커버리에서 차단되어서는 안 됩니다. 합리적인 TTL로 디스커버리 문서를 캐시하고 오래되었으면 빠르게 실패하세요 — 서드파티 IdP를 기다리며 로그인 페이지를 절대 걸어두지 마세요.
빠른 확인
Check yourself
0/4AILmanac 관련 문서
- Claude 사용자를 위한 ChatGPT — Claude에서 넘어온다면 필요한 멘탈 모델 지도
- MCP 2026-07-28: 무상태 스펙 — Anthropic 쪽 생태계의 자매 변경 사항
- MCP Apps (SEP-1865) — 인터랙티브 UI를 위한 첫 공식 MCP 확장, OpenAI Apps SDK의 상대편
- 모델 선택하기 — 크로스 프로바이더 의사결정 프레임워크
출처 및 추가 자료
- 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