게이트웨이를 통한 ChatGPT 로그인

이 방식을 사용하는 이유

이미 모델 게이트웨이를 보유하고 API Platform으로 Codex를 사용하고 있다면, 게이트웨이를 유지하면서 ChatGPT로 로그인 으로 전환할 수 있습니다. 이렇게 하면 모델 게이트웨이를 유지하면서 사용 자격이 있는 ChatGPT 워크스페이스 기능과 제어 옵션(예: 음성 모드)을 이용할 수 있습니다. 기능 가용성에서 로그인 방식을 비교해 보세요.

설정 방법

기존 명령 기반 인증은 게이트웨이 키를 Authorization에 넣습니다. ChatGPT로 로그인하면 이 헤더에 ChatGPT 토큰이 담깁니다. 별도의 게이트웨이 자격 증명을 제공할 방법을 선택하세요.

  • 옵션 A: 간단한 실행 헬퍼를 통해 자격 증명 명령을 재사용합니다. 동일한 게이트웨이 키를 별도의 헤더로 전송합니다.
  • 옵션 B: Codex가 네이티브 OAuth를 통해 게이트웨이 자격 증명을 가져오도록 합니다.

관리형 구성에서 워크스페이스의 클라우드 관리형 requirements.toml에 선택한 공급자 구성을 추가합니다. 이 요구 사항은 사용자가 ChatGPT로 로그인한 후에 적용되며, 다른 로그인 방식을 제한하지 않습니다. 게이트웨이의 Codex 호환 기본 URL은 /models 및 /responses를 https://chatgpt.com/backend-api/codex으로 프록시해야 합니다.

옵션 A: 헬퍼로 자격 증명 명령 재사용

기존 자격 증명 명령을 유지합니다. 간단한 헬퍼가 Codex를 시작하기 전에 해당 명령을 실행하고 출력을 GATEWAY_KEY로 내보냅니다. 현재 사용하는 것과 동일한 게이트웨이 키이며, 전달에 사용하는 헤더만 달라집니다.

예를 들어 기존 API/공급자 구성에 다음 내용이 포함되어 있을 수 있습니다.

# config.toml — existing API/provider setup
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/v1"
requires_openai_auth = false

[model_providers.enterprise_gateway.auth]
command = "/usr/local/bin/fetch-gateway-token"

ChatGPT 로그인을 사용하려면 해당 공급자를 다음 관리형 구성으로 교체합니다. auth 블록을 제거하세요. 명령 기반 공급자 인증은 requires_openai_auth = true와 함께 사용할 수 없습니다.

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
env_http_headers = { "X-Gateway-Key" = "GATEWAY_KEY" } # Send the same gateway key separately.

CLI에서는 다음 셸 함수와 같은 실행 헬퍼를 사용합니다. 명령과 인수를 기존 auth 블록의 값으로 바꾸세요.

codex_with_gateway() (
  set -eu
  GATEWAY_KEY=$(/usr/local/bin/fetch-gateway-token)
  test -n "$GATEWAY_KEY"
  export GATEWAY_KEY
  exec codex "$@"
)

codex_with_gateway

게이트웨이가 X-Gateway-Key를 수신하고 키를 검증한 다음, 요청을 백엔드로 전달하기 전에 해당 헤더를 제거하도록 구성합니다. 이제 클라이언트의 요청에는 다음 내용이 담깁니다.

Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
X-Gateway-Key: <same gateway key returned by your command>

헬퍼는 시작할 때마다 한 번 실행됩니다. Codex는 헬퍼를 다시 실행하거나 이 헤더를 갱신하지 않습니다. 키가 만료되면 새 키를 발급받고 다시 시작하세요. 데스크톱에서는 실행 연동을 통해 앱 프로세스에 GATEWAY_KEY를 제공해야 합니다. Codex가 게이트웨이 로그인과 토큰 갱신을 관리하도록 하려면 옵션 B를 선택하세요.

다이어그램에서는 요청 헤더와 실행 헬퍼를 간략하게 표시합니다. Authorization: Bearer <ChatGPT token>를 사용하고 위 예시에서 헬퍼가 빈 키를 검사하는 부분을 유지하세요. GATEWAY_KEY가 비어 있으면 Codex는 X-Gateway-Key를 생략합니다.

옵션 A: 실행 헬퍼를 통해 자격 증명 명령을 재사용합니다. 동일한 게이트웨이 키가 Authorization에서 X-Gateway-Key로 이동하고, ChatGPT 로그인이 Authorization을 제공합니다.
옵션 A 실행 시: 게이트웨이가 X-Gateway-Key를 검증하고 제거한 다음, ChatGPT Authorization과 계정 ID가 있으면 이를 변경 없이 Codex 백엔드로 전달합니다.

옵션 B: 네이티브 게이트웨이 OAuth 사용

명령과 실행 헬퍼를 Codex가 관리하는 게이트웨이 로그인으로 대체하려면 이 옵션을 사용하세요. 게이트웨이에는 OAuth 인증 서버가 있어야 합니다. PKCE를 사용하는 인증 코드 흐름을 지원하는 공개 클라이언트를 등록한 다음, 예시 URL과 클라이언트 ID를 바꾸세요. 기존 공급자의 auth 블록을 제거하고 다음 관리형 구성을 사용합니다.

# requirements.toml
model_provider = "enterprise_gateway"

[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.

[model_providers.enterprise_gateway.gateway_oauth] # Add gateway OAuth.
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
delivery = { kind = "cookie", name = "auth-openid" } # Add gateway auth as a cookie.
# redirect_port = 43127

Codex는 기본적으로 사용 가능한 루프백 포트를 사용합니다. ID 공급자가 고정 리디렉션 URI를 요구하는 경우, 이 예시에서는 redirect_port를 설정하고 http://127.0.0.1:43127/callback를 등록하세요.

옵션 B: API key 기반 게이트웨이 인증을 ChatGPT 로그인과 함께 사용하는 네이티브 게이트웨이 OAuth로 대체합니다.
옵션 B 실행 시: 게이트웨이가 자체 OAuth 쿠키를 처리하고 ChatGPT 자격 증명을 Codex 백엔드로 전달합니다.

라우팅 헤더 추가(선택 사항)

어느 옵션을 사용하든 Codex는 게이트웨이에 사용자 지정 라우팅 헤더를 전송할 수 있습니다. 예를 들어 클라우드 관리형 enterprise_gateway 공급자에 사용할 다음 헤더를 동일한 requirements.toml에 추가합니다.

[model_providers.enterprise_gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'

Codex는 모델 공급자 요청에 헤더를 포함하여 전송하고, 게이트웨이는 라우팅 규칙을 적용합니다. Codex 프로세스 환경에서 읽어 오는 값에는 env_http_headers를 사용하세요. 요청을 테스트하여 게이트웨이가 두 헤더를 모두 수신하고 의도한 경로를 선택하는지 확인합니다. 더 많은 헤더 옵션은 사용자 지정 모델 공급자를 참조하세요.

자격 증명의 전달 경로 분리 유지

Codex는 ChatGPT Authorization 헤더, 존재하는 모든 ChatGPT-Account-ID 헤더, 게이트웨이 헤더 또는 쿠키를 전송합니다. 게이트웨이가 자체 자격 증명을 검증하고 제거한 다음, ChatGPT 헤더를 변경 없이 전달하도록 하세요.

주의 사항 및 제한 사항

  • 관리형 모델 공급자 요구 사항을 지원하는 Codex 빌드를 사용하세요. 옵션 B를 사용하려면 네이티브 게이트웨이 OAuth도 지원해야 합니다. 이전 빌드는 지원하지 않는 필드를 무시하거나 거부할 수 있습니다.
  • 이 경로는 선택한 모델 공급자를 통한 요청에 적용됩니다. ChatGPT 로그인, MCP, 플러그인 및 기타 앱 연결은 다른 경로를 사용할 수 있습니다.
  • 게이트웨이는 요청 데이터와 두 자격 증명을 모두 볼 수 있습니다. 로그에서 이를 가리고, 게이트웨이 자격 증명을 업스트림으로 전달하지 마세요.
  • 네이티브 게이트웨이 OAuth에는 브라우저와 접근 가능한 루프백 콜백이 필요합니다. 기기 코드 방식으로 대체하는 기능은 없습니다. 새로 고침 토큰이 없으면 액세스 토큰이 만료될 때 사용자가 브라우저에서 다시 로그인해야 합니다.
  • 일반적인 OpenAI /v1/models 응답만으로는 충분하지 않습니다. Codex는 models 배열을 기대합니다. 모델 목록, 프롬프트, 배포 환경에서 사용하는 각 기능을 테스트하세요.

게이트웨이를 통한 음성

이 설정은 Codex 모델 공급자 요청의 경로를 지정하며, ChatGPT Voice를 활성화하지는 않습니다. WebRTC 음성 세션에서는 통화 생성과 사이드밴드 연결이 별도의 경로를 사용합니다. 실험적 experimental_realtime_webrtc_call_base_url 설정은 ~/.codex/config.toml에서 통화 생성을 위한 HTTP 기본 URL만 변경합니다. 사이드밴드 연결, 미디어 또는 일반 모델 요청의 경로는 변경하지 않습니다. 이 재정의를 사용하기 전에 OpenAI와 협력하여 통화 대상과 자격 증명 처리를 확인한 다음, 전체 음성 세션을 테스트하세요.

API/공급자 자격 증명 경로는 게이트웨이 호환성 및 게이트웨이 배포를 참조하세요. 이러한 관리형 설정은 관리형 구성 및 구성 참조를 참조하세요.