Hello,
Our app was published today but we are experiencing an inconsistency between dev and published modes when using OAuth with Dynamic Client Registration (DCR) in our MCP integration.
In development mode, the system correctly calls the registration_endpoint (/oidc/register), creates a client, and uses the returned client_id in the /authorize request, so the flow works as expected.
However, in the published app, the registration_endpoint is never invoked (no DCR logs appear in Auth0), and the system directly calls /authorize with a hardcoded or stale client_id (iNyxAsfE2PBz3f73w3PoIZLm9cLLHmux), which does not exist, resulting in an Unknown client error. Both environments use the same .well-known configuration and a fully functional registration endpoint. It appears that the published connector is skipping the DCR step and using an invalid client.
Could you please help us understand why the published app is not triggering DCR and how we can reset or fix this behavior?
Hey @Aiterna-Technologies, thanks for bringing this up, that difference between dev and published isn’t expected.
What’s likely happening here is the published connector is reusing a stale or invalid `client_id` instead of triggering DCR again. So even though your setup is correct, the flow is skipping the registration step.
A couple things worth trying:
- If that `client_id` was previously registered and later removed in Auth0, try fully disconnecting and reconnecting the connector so it forces a fresh DCR flow
- Double check your published app is still serving the same `.well-known` metadata, especially `registration_endpoint` and PKCE support (`code_challenge_methods_supported: ["S256"]`)
If you’ve validated those and it still skips DCR:
- Collect logs (server logs, component console, ChatGPT tool call transcript) and screenshots
- Note the exact prompt and any confirmation dialogs
- Share everything with your OpenAI partner contact so they can reproduce it internally
This should help narrow down if it’s just cached state vs something deeper in the published flow.
-Mark G.
Hi Mark,
Thanks for the suggestions. We’ve tried the steps you mentioned, including fully disconnecting and reconnecting the connector as well as verifying the .well-known metadata and PKCE configuration. However, the issue still persists.
The root cause appears to be that the previously registered client_id was unintentionally deleted on the Auth0 side, while the published connector continues to reuse that cached client_id instead of triggering a new DCR flow. Because of this, even when attempting to create a new version of the already approved app, the same stale client_id is being used.
As a workaround, we created a new app and submission with the same app name and configuration, only updating the Auth0 client binding. No functional or behavioral changes have been made to the application itself.
Would it be possible to expedite the review process for this new submission?
Thanks
Hi @Aiterna-Technologies, I see what happened, and that workaround makes sense.
The tricky part is that once an app is published, the submitted setup is locked, so deleting or changing the original Auth0 client on the IdP side will not trigger a fresh DCR flow on that published app. Creating a brand new app submission is usually what causes the delay here, since it goes through a separate review path.
The better path is to create a new draft version of the existing published app and resubmit that version, with the Auth0 client change called out clearly in the release notes. That gives reviewers the right context that this is just a binding fix, not a behavior change.
On expediting, I cannot promise timing here, but adding that explanation in the submission notes usually helps avoid confusion during review. If you already submitted the new app, it may be worth resubmitting as a draft version of the original app instead.
-Mark G.
Mark, thank you for your quick response and explanations. However, the issue is that even when we create a new draft version for the approved app, the old cached client ID is still being used and appears as locked. Since the only way to generate a new client ID and trigger DCR is by creating a new app, we proceeded in that way. We also added a explanation to the submission as a release note.
Hi @Aiterna-Technologies, I get why you went that route, the “locked” client ID with no obvious way to refresh it is pretty puzzling.
What’s tricky here is the docs do recommend not creating a new app for updates, but they also don’t actually explain a supported way to force a new client ID or re-trigger DCR from a draft. So the step you took is based on how the system behaves, not something clearly documented.
You’re not the only one hitting this gap. Right now there’s just no explicit flow for “refreshing” that state without starting over.
I’ll pass this back to the team as feedback since this is exactly the kind of edge case the docs should cover better. In the meantime, adding context in the release notes like you did is the right move so reviewers understand why a new app was created.
If anyone else has found a cleaner way to trigger DCR without recreating the app, definitely worth sharing here.
-Mark G.