Missing 'openid' scope in dynamically registered OAuth clients

[mikkokutilainen]

When adding a new app, ChatGPT automatically creates an OAuth client using Dynamic Client Registration. However, the generated client does not include the openid scope. As a result, subsequent authentication attempts fail because ChatGPT requests the openid scope during the authorization flow, which the client has not been configured to support.

Our .well-known/oauth-protected-resource includes scopes_supported with openid included.

We are using Clerk as our auth server.

Anyone experiencing same issue?

[Mohamed_Mamdouh]

@mikkokutilainen I am experiencing the same, Did you manage to find a workaround for this?

[Evan_Fenster]

Hi @mikkokutilainen @Mohamed_Mamdouh , we encountered the same issue.

You may be able to go in and manually add openid after the initial registration, but this is sometimes tricky with the timing. Another solution is to manually create the client in Clerk with openid and the other fields included, and then add the Oauth client ID and Oauth client secret manually when creating the App in ChatGPT (screenshot attached).

Let me know if either of these work for you, or if you find a more reliable way to get openid working with DCR.

[Mohamed_Mamdouh]

Hi @Evan_Fenster
Second way conceptually should work but it does not take advantage of oAuth Dynamic Registration feature in clerk and definitely will need more development effort.

I am trying a work around now and if worked will share it shortly

[OpenAI_Support]

Hey @mikkokutilainen @Mohamed_Mamdouh, yeah, that’s a confusing one.

When using DCR, ChatGPT handles the OAuth client creation automatically, but it still depends on the provider correctly supporting standard OAuth/OIDC behavior, as outlined in the Developer Mode & MCP Apps guide. If a required scope isn’t included at registration time but is later requested during auth, the flow can fail.

Quick checks that would help:

• Is openid present in the DCR request and Clerk is dropping it?
• Or is it missing already in the registration payload?
• Rough timestamp with timezone of a failed attempt?

If this happens consistently with a fresh app and fresh DCR, that’s useful signal. Let’s narrow down whether this is Clerk specific or something broader.

[Mohamed_Mamdouh]

@OpenAI_Support Thanks for the input, Just FYI, Regarding Clerk, my same MCP server when being used with Claude the web app, it requests the scopes and i can see it in Clerk. So I don’t think the issue related to Clerk

[Yingzxu]

Hey @mikkokutilainen have you found a workaround? I’m hitting the same issue

[Yingzxu]

I’ve managed to implement a workaround by pointing the OAuth app registration endpoint to our own API. This allows us to patch the requested scope before it hits Clerk, which seems to be working well for our implementation.

[elviin]

@OpenAI_Support

ChatGPT’s actual DCR call omits openid

When I click Connect in ChatGPT’s Developer Mode against the same MCP URL, the resulting OAuth application in the authorization server’s dashboard has:

- name: ChatGPT

- scopes: email offline_access profile ← openid is missing

- client_id: dcr-generated-id

The subsequent /authorize step then fails with the authorization server’s internal state-validation error (which translates to an invalid_scope-class condition, since

ChatGPT’s /authorize request does include scope=openid … but the just-registered client wasn’t permitted it).

Diagnosis

ChatGPT’s DCR scope-list builder and /authorize scope-list builder disagree about openid:

- /authorize: correctly includes openid (consistent with OIDC Core §3.1.2.1, since it needs an ID token for user identity).

- DCR registration POST: omits openid from the scope field, despite our .well-known/oauth-protected-resource scopes_supported advertising it.

Result: every fresh Developer-Mode connection creates an OAuth client that cannot fulfill the /authorize request that follows. The only workaround currently is to PATCH openid into each freshly-created client by hand (or via a script targeting the provider’s admin API).

Please confirm whether ChatGPT’s MCP connector is intended to:

- (a) read scopes_supported from the protected-resource metadata and include those scopes in the DCR scope field, or

- (b) include only a hardcoded scope set in DCR.

If (a), there’s a bug in the DCR scope-list builder — it isn’t reading our metadata. If (b), then openid should be part of that hardcoded set (since /authorize requires it for OIDC anyway, which ChatGPT clearly relies on for user identity).