Sign in with ChatGPT 정리 — OAuth 흐름, 파트너 6곳, 조직 차단 설정까지

mini_knows·2026년 8월 9일

AI트렌드 OpenAI OpenID Connect Sign in with ChatGPT oAuth supabase

AI 트렌드·이슈

목록 보기

68/120

안녕하세요, 미니지식공간입니다.

Sign in with ChatGPT가 베타로 열리면서 OpenAI가 아이디 제공자(identity provider) 자리에 들어왔습니다. 이 글은 Sign in with ChatGPT의 OAuth 흐름, ID 토큰에 실리는 클레임, 조직 단위 통제 설정을 개발자 관점에서 뜯어봅니다.

사실관계부터 정리

항목	내용	출처
기능명	Sign in with ChatGPT (Continue with ChatGPT)	OpenAI 헬프센터
성격	ChatGPT 계정 신원으로 외부 앱 계정 생성·연결·로그인	OpenAI 헬프센터
공개일	2026-08-02 라이브 베타(매체 보도) / 파트너 Supabase 블로그는 2026-07-29	Tech Times, Supabase
제공 범위	전 세계, 인증된 ChatGPT 사용자(Enterprise 포함)	OpenAI 헬프센터
적용 지점	OpenAI Academy, Codex Sites, 일부 플러그인·파트너 사이트 순차 적용	OpenAI 헬프센터
초기 파트너	Airtable, GitLab, HubSpot, Notion, Supabase, Vercel	OpenAI 헬프센터

공개 일자는 출처가 엇갈린다. Tech Times는 2026년 8월 2일 라이브 베타 공개로 보도했고, 런치 파트너인 Supabase의 블로그 글은 2026년 7월 29일자다. OpenAI 헬프센터 문서 본문에는 공개 일자 표기가 없다. OpenAI 측 공식 공개 일자는 확인 필요로 둔다.

프로토콜 레이어에서 무슨 일이 일어나나

Tech Times는 이 기능이 OAuth 2.0(RFC 6749, 2012)과 그 위에 얹히는 신원 계층인 OpenID Connect 조합으로 구현됐고, 인가 코드(Authorization Code) 흐름을 따른다고 설명한다. OpenAI 헬프센터 문서에는 프로토콜 명칭이 명시돼 있지 않으므로, 이 부분은 매체 분석에 근거한 설명이며 공식 확인이 필요한 항목이다. 다만 인가 코드 흐름 자체는 표준 규격이라 파라미터 구조는 그대로 참고할 수 있다.

RFC 6749 4.1.1절이 정의하는 인가 요청은 아래 형태다. 아래 파라미터는 표준 문서에 정의된 것이며, Sign in with ChatGPT 전용 엔드포인트 주소는 공개 문서에서 확인되지 않아 자리표시자로 남긴다.

GET /authorize
  ?response_type=code
  &client_id=<CLIENT_ID>
  &redirect_uri=<REDIRECT_URI>
  &scope=openid%20profile%20email
  &state=<CSRF_TOKEN>
HTTP/1.1
Host: <AUTHORIZATION_SERVER_HOST>

출처: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1

브라우저가 인가 서버로 리디렉션되고, 사용자가 신원을 확인하면 서버가 수명이 짧은 인가 코드를 발급한다. 파트너 애플리케이션은 그 코드를 액세스 토큰과 ID 토큰으로 교환한다. 신원 클레임(이름, 이메일, 사진)을 실어 나르는 쪽은 ID 토큰이다. 그리고 인가 서버는 어떤 앱이 흐름을 시작했고 어떤 권한이 요청·승인됐는지, 언제 어느 기기와 IP에서였는지를 기록한다.

토큰에 실리는 것과 서버에 남는 것

두 흐름을 분리해서 보는 게 핵심이다. 헬프센터 문서 기준으로 정리하면 다음과 같다.

파트너 앱이 받는 것

이름
이메일 주소
프로필 사진(있는 경우)

이 로그인만으로 공유되지 않는 것

ChatGPT 대화 내용과 메모리
파일과 토큰
결제 정보 및 그 밖의 ChatGPT 계정 데이터

OpenAI가 인증 처리 과정에서 수집하는 것

계정 식별자, 이메일 주소, 인증 제공자, 선택된 워크스페이스 또는 조직
애플리케이션 식별자, 요청 및 승인된 권한, 인가 결정, 로그인 결과
요청·세션 식별자, IP 주소, 요청에서 추정한 위치, 브라우저 또는 앱 버전, 사용자 에이전트, 기기 식별자, 보안 신호

파트너 앱이 추가 접근을 요구하면 그것은 로그인과 분리된 별도 권한 흐름이며, 사용자나 조직 관리자가 승인한 범위로 제한된다. 수집된 인증 이벤트 로그의 보관 기간과 모델 학습 활용 여부는 공개 문서에 언급이 없어 확인 필요로 남는다.

한 가지 설계상 차이는 이메일 처리다. Tech Times는 Sign in with Apple이 앱마다 다른 릴레이 주소를 제공해 서비스 간 계정 대조를 막는 반면, Sign in with ChatGPT는 기본적으로 실제 이메일을 공유한다고 비교했다. 사용자 식별자를 이메일 해시로 잡는 백엔드라면 이 차이가 그대로 영향을 준다.

파트너 통합은 실제로 어떻게 붙나

Supabase가 공개한 문서가 가장 구체적이다. 적용 지점은 supabase.com 로그인 페이지와 ChatGPT 안의 Supabase 플러그인 두 곳이고, 플러그인은 데스크톱·웹·모바일에서 모두 동작한다.

계정 병합 규칙은 이렇게 정리된다.

사용자 상태	결과
Supabase 신규	ChatGPT 로그인으로 계정 생성, 이후 그 신원으로 관리
기존 계정 + 동일 이메일	자동 연결, 새 계정 생성 없음, 기존 로그인 수단 유지
SSO 계정	예외로 분리 유지

ChatGPT 안에서의 연결은 플러그인 디렉터리에서 Supabase 추가 → ChatGPT로 로그인 → 동의 화면 확인 → 대화 복귀 순서다. 로그인과 권한 부여가 분리돼 있고, 연결 해제는 Supabase 대시보드에서 가능하다. 신규 사용자는 대시보드에서 조직을 먼저 만들어야 ChatGPT에서 프로젝트를 생성할 수 있다.

조직 단위로 통제하기

기본값이 중요하다. 별도 정책을 설정하지 않은 조직에서는 Sign in with ChatGPT가 활성화 상태다. 기존 허용·차단 정책과 승인된 애플리케이션 목록은 유지되며 덮어쓰이지 않는다. 글로벌 관리자는 관리자 콘솔에서 Access → External Access로 이동해 다음을 조정한다.

Enable Sign in with ChatGPT for your organization을 꺼서 조직 전체 사용 차단
Approved applications를 켜서 승인된 앱에서만 사용 허용
Approved 컨트롤로 앱별 승인 관리

여기서 헷갈리기 쉬운 점 하나. 위 설정은 아이디 제공자 로그인 옵션을 통제하는 것이고, Codex 클라이언트가 ChatGPT 계정으로 로그인하는 것은 별개 레이어다. 후자는 관리형 설정 파일로 강제할 수 있는데, 공식 Codex 문서에 아래 옵션이 정의돼 있다.

# 로그인 방식 강제: ChatGPT 로그인만 또는 API 키 로그인만 허용
forced_login_method = "chatgpt"  # 또는 "api"

# ChatGPT 로그인 사용 시 특정 워크스페이스로 제한
forced_chatgpt_workspace_id = "00000000-0000-0000-0000-000000000000"

# 자격증명 저장 위치: file | keyring | auto
cli_auth_credentials_store = "keyring"

출처: https://learn.chatgpt.com/codex/auth

활성 자격증명이 위 제약과 맞지 않으면 Codex는 사용자를 로그아웃시키고 종료한다. file 저장을 쓰면 자격증명은 CODEX_HOME(기본값 ~/.codex) 아래 auth.json에 평문으로 남는다. 공식 문서도 이 파일을 비밀번호처럼 다루고 커밋하거나 티켓·채팅에 붙여넣지 말라고 못박고 있다. 에이전트 도구가 남기는 로컬 토큰 파일이 어떤 사고로 이어질 수 있는지는 Hugging Face 보안 사고 분석 글에서 다룬 적이 있다.

도입 전 점검 체크리스트

우리 조직의 External Access 설정이 기본값(켜짐)인지 확인한다.
사용자 식별을 이메일 기준으로 하고 있다면, 실제 이메일이 그대로 들어오는 전제로 병합 로직을 점검한다.
인증 제공자 장애가 곧 로그인 장애가 되므로 대체 로그인 수단을 남긴다.
로그인과 권한 부여가 분리돼 있으니 동의 화면에서 요구할 스코프를 최소로 잡는다.
CI나 스케줄러에서 도는 자동화는 브라우저 로그인 대신 별도 토큰 체계를 쓴다.

ChatGPT Work와 플러그인 디렉터리가 어떤 구조로 확장돼 왔는지는 ChatGPT Work와 Claude Cowork 비교 글에 정리해 뒀다. 이번 로그인 기능은 그 흐름의 연장선에 있다.

자주 묻는 질문

Sign in with ChatGPT 도입하려면 별도 신청이 필요한가?

현재 공개 문서에서 확인되는 것은 초기 참여 파트너 여섯 곳과 OpenAI Academy, Codex Sites다. 일반 개발자용 셀프서비스 등록 절차나 클라이언트 등록 문서는 공개 자료에서 확인되지 않는다. 이 부분은 확인 필요다.

기존 로그인 코드를 고쳐야 하나?

인가 코드 흐름을 이미 지원하는 백엔드라면 구조 자체를 바꿀 일은 크지 않다. 다만 실제 이메일이 그대로 들어오는 점, 프로필 사진 클레임이 없을 수 있는 점, 계정 자동 연결 정책을 어떻게 잡을지는 별도 결정이 필요하다. Supabase는 동일 이메일이면 자동 연결하되 SSO 계정은 분리하는 방식을 택했다.

대화 내용이 외부 앱으로 새어나갈 위험은 없나?

로그인 자체로는 이름·이메일·프로필 사진만 전달되고 대화, 메모리, 파일, 토큰, 결제 정보는 공유되지 않는다는 것이 공식 문서의 설명이다. 위험 지점은 로그인이 아니라 그 뒤에 이어지는 별도 권한 승인 화면이다. 무엇을 허용하는지 그 화면에서 확인하는 습관이 필요하다.

마무리

Sign in with ChatGPT는 기술적으로 새로운 프로토콜이 아니라, 익숙한 인가 코드 흐름 위에 OpenAI가 인가 서버로 올라선 사건에 가깝습니다. 붙이는 쪽에서는 계정 병합 규칙과 대체 로그인 수단을, 쓰는 쪽에서는 조직 관리자 설정을 먼저 확인하시면 좋겠습니다.

출처