320 VIEWS
핀터레스트 링크드인 LINE

(편집 중 : 최종 업데이트 2026-10-02 12:39 JST) OpenAI가 9 월 29 일 DevDay 2026에서Sign in with ChatGPT (SIWC) 를 공식 발표했습니다. 그래서, 스스로 손으로 체크하거나 해서 기사를 쓰고 싶은 곳입니다만, 조금 지금 시간을 잡을 수 없습니다. 그래서, ChatGPT 자신에게 정리해 준 밑받침을 이하에 붙여 둡니다. 실수 등 발견하면 X로 말해 가르쳐 주세요.

SIWC는 OpenAI가 제공하기 시작했습니다. OpenID Connect Provider / OAuth Authorization Server 기능입니다. 그러나 실제로는 다음 두 가지 기능이 동일한 브랜드 아래에 있습니다.

  1. Identity Sign-in
    ChatGPT 계정을 사용한 거의 표준 OpenID Connect Authorization Code + PKCE.
  2. ChatGPT plan usage
    Plus/Pro 등의 ChatGPT 계약에 포함된 이용 프레임을 외부 OSS/대응 앱에서 OAuth Access Token에서 Responses API로 가져와 사용하는 방법.

후자가 꽤 특징적입니다. 이것은 「ChatGPT로 로그인」의 연장이라기보다,ChatGPT subscriber identity + delegated inference entitlement OAuth로 외부 앱에 전달하는 메커니즘입니다. OpenAI 자신도 Identity와 plan usage를 다른 permission이라고 명기하고 있습니다. 1

OpenAI는 2026년 9월 23일에 일부 partner site/plugin에의 Identity 기능의 rollout을 개시하고, 9월 29일의 DevDay 2026에서 ChatGPT plan usage를 포함한 형태를 공식적으로 발표하고 있습니다.

Identity Sign-in

Identity 부분은 거의 보통의 OpenID Connect

OpenAI의 production Discovery Document는 실제로 공개 2.

주요 metadata는 다음과 같습니다.

항목값
발급자https://auth.openai.com
승인 끝점https://auth.openai.com/api/accounts/authorize
토큰 엔드포인트https://auth.openai.com/api/accounts/oauth/token
사용자 정보 엔드포인트https://auth.openai.com/api/accounts/oauth/userinfo
Revocation Endpointhttps://auth.openai.com/api/accounts/oauth/revoke
JWKShttps://auth.openai.com/.well-known/jwks.json
응답 _ 유형code 만
부여 _ 유형authorization_code, refresh_token
PKCES256
subject typepublic
ID Token signingRS256
token endpoint authclient_secret_basic, client_secret_post, none

즉 기본형은,

OIDC
  └─ OAuth 2.0 Authorization Code
       └─ PKCE S256

웹사이트에서 Identity만을 사용하는 경우의 Authorization Request는 OpenAI 자체의 예에서는 거의 그대로 전형적인 OIDC입니다.

GET https://auth.openai.com/api/accounts/authorize?
    client_id=oaiapp_...
    &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
    &response_type=code
    &scope=openid%20profile%20email
    &state=...
    &nonce=...
    &code_challenge=...
    &code_challenge_method=S256

스코프는

openid
profile
email

profile 그럼 name/picture 등,email 그러면 email과 email verification claim을 요청합니다. Discovery에도 email_verified 포함하는 표준 OIDC Claims가 열거되었습니다.3

ID 토큰 검증

RP 측은 평소대로 ID Token을 JWKS로 검증합니다.

OpenAI는 명시적으로,

iss
aud
exp
nonce
sub
signature

확인을 요청했습니다.

aud RP의 client_id,iss は

https://auth.openai.com

4

RP에서 ID 키에 대해 OpenAI는

issuer + client_id + sub

유지하는 것이 좋습니다.

또 중요한 것은,

email만으로 기존 계정에 자동 링크해서는 안됩니다.

하는 점입니다. email match는 account ownership의 증명으로 간주되지 않습니다. 이것은 올바른 디자인입니다.

Discovery의 subject type은

"subject_types_supported": ["public"]

(출처) https://auth.openai.com/.well-known/openid-configuration

입니다. 따라서 현재 pairwise subject를 advertise하지 않습니다.

Identity-only에서는 Access Token을 사용하지 않음

여기는 약간 재미있는 디자인입니다.

일반 웹 사이트의 SIWC에서 OpenAI는

identity-only sign-in에 필요한 artifact는 id_token. OpenAI access token 또는 refresh token을 요청하지 않도록

로5.

UserInfo endpoint는 Discovery되지만 표준 SIWC Web login 샘플은 UserInfo를 전제로 하지 않습니다. 아직 확인하지 않았기 때문에 여기를 access token으로 두드리면 어떻게 될지 아직 모르겠습니다. Identity-only에서는 Access Token은 돌려주고 싶지 않다(그러나 RFC 6749에서는 REQUIRED이므로 돌려주어야 한다)라는 요구는 거기 여기이기 때문에 기분은 알 수 있습니다. 어쩌면 OAuth WG에서 새로운 Grant Type을 만드는 것이 좋을 것입니다. 다만, 현상에서는 반환해야 하기 때문에 반환한다는 것이 되어 있는 것이 아닐까 생각합니다(←여기, 요 확인). 그렇다면 Access Token은 어디에서 사용되는지 말하면 ... 이것은 후술합니다.

Public client / Confidential client

둘 다 있습니다.

Public client

Token Endpoint Authentication은:

none

에서 PKCE를 사용합니다.

POST /api/accounts/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=...
&redirect_uri=...
&client_id=...
&code_verifier=...

기밀 클라이언트

현재 문서화된 예는 다음과 같습니다.

client_secret_basic

게다가 confidential client에서도 PKCE를 유지합니다.6.

Discovery 자체에는

client_secret_basic
client_secret_post
none

3 가지 방법이 advertise되었습니다7.

ChatGPT plan usage : 구독을 사용하여 OpenAI 모델 사용

ChatGPT plan usage에 대한 액세스 토큰 얻기

글쎄, 처음에 말했듯이, Signin with ChatGPT는ChatGPT plan usage외부 앱이 OpenAI Responses API를 호출 할 수있는 권한을 사용자의 ChatGPT라고합니다. plan에서 OAuth로 delegation하기 위한 것입니다. 이것을 사용하면 해당 외부 앱(client)은 OpenAI의 모델을 지정하여 다양한 것(tool을 사용하여 웹을 읽거나 파일을 읽고 쓰거나, 생각하거나 그 결과를 출력하거나)할 수 있게 됩니다.

flowchart TD A["Application"] B["Responses API"] C["Model"] D["Web search"] E["Files"] F["Code"] G["Computer"] H["MCP server"] A --> B B --> C C --> D C --> E C --> F C --> G C --> H

그래서

Responses API = OpenAI 모델을 사용한 agent execution의 기본 primitive

그리고 이해하는 것이 좋습니다.

자,이 delegation을하기 위해 access token이 필요하지만 SIWC에서 클라이언트는 Authentication request에서scope요청하여 얻습니다.8.

openid
profile
email
offline_access
resource.invoke
chatgpt.tokens.use.direct

또한 이것뿐만 아니라

resource=https://api.openai.com/v1

또한 Authorization Request와 Token Request에 붙여야합니다.

이것은 형태로 RFC 8707 Resource Indicators for OAuth 2.0 9 입니다. RFC 8707은 resource절대 URI로 대상 Resource Server를 지정하는 메커니즘입니다.

따라서 개념적으로는

           OpenAI Authorization Server
             auth.openai.com
                    │
                    │ Access Token
                    ▼
              External OSS app
                    │
                    │ Bearer AT
                    ▼
          OpenAI Resource Server
          api.openai.com/v1

입니다.

액세스 토큰 aud 심지어

"aud": "https://api.openai.com/v1"

で す10. Userinfo Endpoint가 아닙니다.

Access Token 예제

OpenAI가 공개하는 payload는 개념적으로 이렇게 되어 있습니다.

{
  "sub": "...",
  "aud": "https://api.openai.com/v1",
  "client_id": "oaiapp_...",
  "scope":
    "chatgpt.tokens.use.direct email offline_access openid profile resource.invoke",

  "https://api.openai.com/auth": {
    "per_user_salt": "...",
    "encrypted_auth_metadata": "..."
  },

  "iss": "https://auth.openai.com",
  "iat": 1790032532,
  "exp": 1790036132,
  "jti": "...",
  "nbf": 1790032532
}

즉 Access Token도 JWT입니다.

수명은

  • 액세스 토큰: 1 시간
  • Refresh Token: 30 일
  • Refresh마다 Refresh Token rotation
  • 새로운 Refresh Token에 다시 30일의 lifetime

현시점의 문서에서는 DPoP등의 sender-constraining은 사용되고 있지 않고, Responses API에는 통상의

Authorization: Bearer <ACCESS_TOKEN>

로 보냅니다.11.

Responses API에서 ChatGPT subscription 사용

예를 들어,

POST https://api.openai.com/v1/responses
Authorization: Bearer <SIWC_ACCESS_TOKEN>
Content-Type: application/json

{
  "model": "...",
  "input": [...],
  "store": false,
  "stream": true
}

OpenAI는 SIWC plan usage에 대해 현재,

store: false
stream: true

필수입니다. 12.

즉, 이것은 일반 API 키를 OAuth token으로 바꿔 놓은 것만은 아닙니다.

Responses API의 일부 기능에도 제한이 있으며, 예를 들어 현재 preview에서는

  • background
  • 지속 conversation
  • previous_response_id over HTTP
  • hosted MCP/connectors
  • 이미지 생성
  • 파일 검색
  • 코드 인터프리터
  • native computer use

등을 사용할 수 없습니다.13

がって API subscription을 OAuth화한 것조금 다릅니다.

SIWC 자체 확장

네 번째 클라이언트 등록 방법 : dynamic_agent_client

일반 OAuth는 클라이언트를 사전 등록하거나 RFC 7591 Dynamic Client Registration Endpoint를 사용합니다. OpenID 컨텍스트에서는 최근에는 OpenID Federation을 사용한다는 것도 있습니다.

SIWC의 OSS 흐름은 둘 다 다릅니다.

최초의 Authorization Request에서,

client_id=dynamic_agent_client

라는 특수한 pseudo-client를 사용합니다.

또한,

agent_name_hint
ext_agent_host_id

를 붙입니다.14

예:

GET https://auth.openai.com/api/accounts/authorize?

 client_id=dynamic_agent_client
 &agent_name_hint=OpenClaw
 &ext_agent_host_id=urn:uuid:...
 &response_type=code
 &redirect_uri=http://127.0.0.1:1455/auth/callback

 &scope=openid profile email
        offline_access
        resource.invoke
        chatgpt.tokens.use.direct

 &resource=https://api.openai.com/v1

 &state=...
 &nonce=...
 &code_challenge=...
 &code_challenge_method=S256

그리고 callback이,

?code=...
&state=...
&client_id=oaiapp_xxxxx

되고,여기서 공식적인 client_id가 발행됩니다.15. 요점은, authorization request 어느 동시에 client regsitration도 해 버리는 느낌이군요.

그 후 Token Endpoint에는,

dynamic_agent_client

대신 이 새로 발행된

oaiapp_xxxxx

보내드립니다.

이는 RFC 7591 Dynamic Client Registration과 명확하게 다릅니다.

RFC 7591이라면 일반적으로

POST registration_endpoint
       ↓
client_id
client_secret...

SIWC OSS flow는

sequenceDiagram autonumber participant C as OSS Client / Agent participant B as Browser participant AS as OpenAI Authorization Endpoint participant U as User C->>C: Generate state, nonce, code_verifier / code_challenge C->>B: Open authorization URL B->>AS: GET /api/accounts/authorize client_id=dynamic_agent_client response_type=code redirect_uri=http://127.0.0.1:PORT/callback scope=openid profile email ... code_challenge=... code_challenge_method=S256 AS->>U: Authenticate user U-->>AS: Authentication completed AS->>U: Show consent / application registration U-->>AS: Approve Note over AS: Create/register a concrete client and issue client_id = oaiapp_... AS-->>B: HTTP Redirect to redirect_uri ?code=AUTH_CODE &state=STATE &client_id=oaiapp_... B-->>C: GET /callback code=AUTH_CODE state=STATE client_id=oaiapp_... Note over C: Store issued oaiapp_... client_id Use it for the token request, not dynamic_agent_client

따라서

user-mediated dynamic registration embedded into an Authorization Request

라고 보는 것이 적절합니다.

RFC 7591호환되는 Dynamic Client Registration이라고 부르지 않는 것이 좋습니다.

ext_agent_host_id

이것은 흥미로운 OpenAI 확장입니다.

OSS client와는 별도로,

agent host

라는 개념이 있습니다.

예를 들어,

flowchart TD A["One SIWC client registration"] B["client_id"] A --> B B --> C["Laptop"] B --> D["VM"] C --> E["ext_agent_host_id A"] D --> F["ext_agent_host_id B"]

라는 모델입니다.16.

host ID에는 OpenAI가 현재,

추천

urn:ietf:params:oauth:jwk-thumbprint:...

RFC 9278 JWK Thumbprint URI

대신

urn:uuid:<uuid>

ま た は

did:key:...

인정17

그러나 매우 중요한 것은 현재로서는

JWK Thumbprint를 사용해도 private key possession을 OpenAI는 검증하지 않았다

라는 점입니다.18

따라서

JWK thumbprint host ID
 ≠ proof-of-possession
 ≠ DPoP
 ≠ client authentication

현재는 단순한 stable host identifier입니다.

네이티브 앱으로는 RFC 8252를 상당히 따라

OSS desktop/client에서,

http://127.0.0.1:{port}/auth/callback

를 사용합니다.

localhost 사용하지 않고 IP literal 127.0.0.1 를 요청합니다. 포트 번호만 sign-in마다 변경 가능19.

이것은 RFC 8252의 루프백 인터페이스 리디렉션과 일치합니다.RFC 8252자신도,

http://127.0.0.1:{port}/...

을 정의하고 native app에서 PKCE를 사용하도록 요청합니다.

Returning login과 id_token_hint

일단 등록하면 다음 번부터,

client_id=<issued oaiapp_...>
ext_agent_host_id=...
id_token_hint=<previous ID Token>
login_hint=user@example.com

사용할 수 있습니다.

흥미롭게도 OpenAI는 이전 expired ID Token에서도 id_token_hint 로 사용할 수 있는라고 명시하고 있습니다.20.

こ れ はOpenID Connect Core 1.0벗어나지 않습니다.

OIDC Core 자신,

id_token_hint 는current or past authenticated session을 나타내는 hint

그리고 OP가 발행 한 것이라면,exp 를 지나고 있어도 recent session이었던 경우는 받아들이는 것을 추천하고 있습니다.

따라서 이 부분은 꽤 OIDC인것 같은 구현입니다.

Discovery metadata에는 약간 불일치가 있습니다.

표준화의 관점에서는 현재 가장 신경이 쓰이는 부분입니다.

Discovery document의 :

"scopes_supported": [
  "openid",
  "profile",
  "email",
  "offline_access"
]

는

resource.invoke
chatgpt.tokens.use.direct

가 없습니다. OpenAI

그러나 공식 SIWC documentation은 분명히,

offline_access
resource.invoke
chatgpt.tokens.use.direct

요청합니다.21.

이것은 사양상 반드시 치명적이지는 않지만,

Discovery metadata에서만 SIWC plan-usage capability를 찾을 수 없음

됩니다. 그래서 추가하는 것이 좋습니다.

마찬가지로,

resource=https://api.openai.com/v1

RFC 8707로 사용하고 있지만 SIWC 관련 plan usage capability discovery metadata는 없습니다.

따라서 현상은

OIDC discovery
   +
out-of-band OpenAI SIWC profile documentation

둘 다 읽어야합니다.

ChatGPT Plugin의 경우 OAuth가 이중입니다.

ChatGPT 플러그인과의 통합은 더욱 흥미로운 구조입니다.

OpenAI 설명에서,

ChatGPT
   │
   │ outer OAuth
   ▼
Plugin / external application
   │
   │ inner SIWC/OIDC
   ▼
OpenAI Authorization Server

で す22.

Outer transaction

ChatGPT → Plugin:

/oauth/authorize
  ?response_type=code
  &client_id=CHATGPT_CONNECTOR_CLIENT_ID
  &redirect_uri=...
  &scope=...
  &state=...
  &code_challenge=...
  &code_challenge_method=S256
  &resource=...
  &login_hint=...
  &target_flow=chatgpt_siwc

내부 transaction

Plugin → OpenAI:

openid profile email

SIWC.

Plugin 측은 OpenAI ID Token을 확인하여 local account를 확인한 다음 Outer OAuth를 다시 시작합니다.23.

따라서

SIWC는 Plugin 자체의 OAuth Authorization Server를 대체하지 않습니다.

라는 것이 중요합니다.

Identity federation의 내부 레이어로 들어갑니다.

Identity와 Authorization은 의도적으로 분리되어 있습니다.

전체를 정리하면 :

flowchart TD A["OpenAI / ChatGPT account"] A -->|"OIDC Authentication openid profile email"| B["Application"] B -->|"Application's own session"| C["Local session"] B -->|"Optional authorization chatgpt.tokens.use.direct resource.invoke"| D["OAuth Access Token"] D -->|"Bearer token"| E["OpenAI Responses API"]

Identity sign-in만으로는

  • ChatGPT 대화
  • 기억
  • 파일
  • 청구 데이터
  • API 키

등은 통과하지 않습니다. OpenAI 도움말 센터

ま た chatgpt.tokens.use.direct 그렇지 않으면 유효한 ID 토큰을 얻어도 ChatGPT plan을 사용하여 inference를 할 수 없습니다. OpenAI 개발자

이 separation은 설계상 꽤 중요합니다.

보안 측면에서 보면

현재 프로파일을 OAuth / OIDC 보안 관점에서 정리하면,

항목SIWC
인증 코드○
PKCE S256○ / 실질 필수
state○
OIDC nonce○
Exact redirect URI○
Native app external browser○
루프백 리디렉션○
refresh rotation○
RFC 8707 스타일 resource○
Sender-constrained AT문서상 없음
DPoP문서상 없음
mTLS문서상 없음
PARDiscovery에 없음
JARrequest 지원되지 않는
쌍으로 sub없음, public 전용
Dynamic registrationOpenAI 고유 방식

Discovery에서는,

"request_uri_parameter_supported": false,
"request_parameter_supported": false

그래서 JAR/request object계는 현재 사용하지 않습니다. 이것은 현재 https://auth.openai.com/.well-known/openid-configuration 에서 볼 수 있습니다.

특히 주목할만한 디자인 포인트

저라면 표준화의 관점에서는 다음의 4점을 특히 봅니다.

① "Sign-in"과 "AI entitlement"의 분리

이것은 좋은 디자인입니다.

authentication != authorization != subscription entitlement

비교적 분명합니다.

② ChatGPT subscription이 OAuth Resource Access가 된다

chatgpt.tokens.use.direct 는 단순한 API scope가 아니라 실제,

"이 ChatGPT 구독자 계약을이 클라이언트에서 소비 할 수 있습니다."

라는 delegation입니다.

종래의 OAuth가 상정하고 있던 「user data/API action」으로부터,economic entitlement delegation 에 scope의 의미가 확산됩니다.

이것은 Agentic Payments와 delegated authority의 관점에서도 꽤 흥미롭습니다.

③ client registration이 user-bound

OSS flow에서issued client_id が,

user + selected workspace

에 bind되었습니다.24

이것은 전통적인,

client_id = software application/deployment

라는 OAuth 모델과는 꽤 다릅니다.

오히려,

client_id ≈ user-authorized agent registration

④ Host identity를 OAuth에 추가하고 있다

또한,

client
user
workspace
host

별도로 다루고 있습니다.

이것은 Agentic AI에서 앞으로 중요해질

Principal
Agent
Client
Runtime
Device/Host

의 identity separation에 꽤 가까운 구조입니다.

한편, 신경이 쓰이는 점도 있다

프로토콜 설계로는 이 부분입니다.

        User
         │
         │ owns
         ▼
 ChatGPT subscription
         │
         │ delegates entitlement
         ▼
       Client
         │
         │ runs on
         ▼
     Agent Host
         │
         │ Bearer AT
         ▼
 Responses Resource Server

그런데 현재,

ext_agent_host_id

하지만 존재하지만 host private key possession은 검증되지 않습니다.

따라서 현재 호스트 식별은

identification

그리고,

cryptographic binding

아니다25.

또한 Access Token은 Bearer입니다.

고가치의 작업을 가리키는 경우에는 장래에 여기를,

JKT / DPoP / attested key

등으로 bind 할 여지는 매우 크다고 생각합니다. FAPI화군요.

정리

Sign in with ChatGPT는 OIDC로서 매우 솔직합니다.

OIDC Authorization Code
+ PKCE S256
+ nonce
+ public sub
+ standard ID Token validation

그 위에 OpenAI 독자 프로필로,

dynamic_agent_client
agent_name_hint
ext_agent_host_id
resource.invoke
chatgpt.tokens.use.direct

놓고,

ChatGPT subscription entitlement
       ↓ OAuth delegation
Responses API

를 실현합니다.

특히 중요한 것은 이것은 단순히 'Sign in with Google의 ChatGPT 버전'이 아니라는 점입니다.Identity Provider + subscriber entitlement authorization + agent/client/host registration system 의 조합이 되어 있습니다.

표준화적으로는RFC 8707 / RFC 8252 /OpenID Connect Core를 상당히 타면서 Dynamic Client Registration과 agent-host binding만 독자적으로 확장하고 있다그리고 정리하면 이해하기 쉽습니다.

脚注

  1. OpenAI, DevDay 2026 되돌아보기
  2. OpenAI OIDC Discovery Document
  3. OpenAI 개발자
  4. OpenAI Developers: On your website
  5. For standard identity-only sign-in, the required artifact is id_token. Don't require an OpenAI access_token or refresh_token; they aren't part of the standard identity-only client contract. source: OpenAI 개발자
  6. OpenAI Developers – Signin with ChatGPT – On your website
  7. OpenAI
  8. OpenAI Developers: Registrations and signin
  9. RFC 8707: Resource Indicators for OAuth 2.0 | RFC Editor
  10. OpenAI 개발자
  11. OpenAI Developers – Signin with ChatGPT – Models and inference
  12. OpenAI Developers – Signin with ChatGPT – Models and inference
  13. OpenAI Developers – Sign in with ChatGPT – Preview limitations
  14. OpenAI Developers: Registration and sign-in
  15. OpenAI Developers – Sign in with ChatGPT – Registration and sign-in
  16. OpenAI Developers-Sigin in with ChatGPT-Overview
  17. OpenAI 개발자
  18. OpenAI Developers – Sign in with ChatGPT – Overview
  19. OpenAI Developers – Signin with ChatGPT – Registration and sign-in
  20. OpenAI Developers-SIWC-Registration and sign-in
  21. OpenAI Developers – Signin with ChatGPT – Registration and sign-in
  22. OpenAI Developers – In your ChatGPT plugin
  23. OpenAI Developers – Sign in with ChatGPT – In your ChatGPT plugin
  24. OpenAI Developers – Signin with ChatGPT – Overview
  25. OpenAI Developers: SIWC – Overview