We're integrating the 3CX MCP Server into our own internal assistant application (used for live agent status, call reports, etc.). Authentication follows the standard OAuth flow the MCP server advertises: automatic discovery of the endpoints, then Dynamic Client Registration (RFC 7591, POST /connect/register), followed by an Authorization Code flow with PKCE.
The core issue: a client registered this way does not seem to get "Persistent" status on the 3CX side. After some period without use, a new authorization attempt using the existing client ID is rejected with something like "unknown client id or redirect url" — it looks like the entire client registration gets discarded server-side, not just the access/refresh token. At that point a plain refresh-token exchange is no longer enough; a completely new, interactive login by a human in the browser is required to re-register and re-authorize.
When using the official claude.ai connector (CIMD flow), the 3CX login/consent page shows an option along the lines of "Persistent client" / "Override console restrictions". With our own MCP client (created via Dynamic Client Registration), that option never appears — presumably because our app isn't requesting/able to request a token with sufficiently long-lived/unrestricted validity. We already explicitly request the standard offline_access scope (even though the server doesn't advertise it in scopes_supported), but that doesn't seem to solve the underlying problem.
To reduce the risk of the registration being "forgotten" due to inactivity, we currently request a valid access token (refreshing it via the refresh token if needed) automatically every 3 minutes — both while the app is running and via a separate, independent scheduled task as a fallback. That's only a workaround, not a reliable fix: we don't know after how long an unused registration is actually discarded by 3CX, so an occasional manual re-login is still sometimes necessary.
Happy to provide more detail — logs, timestamps of the last successful login, the client ID involved — if that helps with diagnosis.
Environment: Version 20.0 Update 10 (Build 1621 Alpha - AI 1.6.57) self-hosted
The core issue: a client registered this way does not seem to get "Persistent" status on the 3CX side. After some period without use, a new authorization attempt using the existing client ID is rejected with something like "unknown client id or redirect url" — it looks like the entire client registration gets discarded server-side, not just the access/refresh token. At that point a plain refresh-token exchange is no longer enough; a completely new, interactive login by a human in the browser is required to re-register and re-authorize.
Observation on the likely cause
When using the official claude.ai connector (CIMD flow), the 3CX login/consent page shows an option along the lines of "Persistent client" / "Override console restrictions". With our own MCP client (created via Dynamic Client Registration), that option never appears — presumably because our app isn't requesting/able to request a token with sufficiently long-lived/unrestricted validity. We already explicitly request the standard offline_access scope (even though the server doesn't advertise it in scopes_supported), but that doesn't seem to solve the underlying problem.
Current workaround
To reduce the risk of the registration being "forgotten" due to inactivity, we currently request a valid access token (refreshing it via the refresh token if needed) automatically every 3 minutes — both while the app is running and via a separate, independent scheduled task as a fallback. That's only a workaround, not a reliable fix: we don't know after how long an unused registration is actually discarded by 3CX, so an occasional manual re-login is still sometimes necessary.
Questions for the community / 3CX AI team
- Is there a way to give a client created via Dynamic Client Registration the same "Persistent" status that official connectors (e.g. claude.ai) seem to get — via a specific scope, registration parameter, or admin setting?
- If not: how long does an unused refresh token / client registration remain valid on the 3CX side before it's discarded?
- Is there a supported way for an internal server-to-server integration like ours to get a genuinely permanent, non-interactive credential for MCP access (e.g. an OAuth client with a client secret created manually in the admin area, with no expiry) instead of relying on a flow designed for interactive user logins that has to be kept alive and occasionally redone manually?
Happy to provide more detail — logs, timestamps of the last successful login, the client ID involved — if that helps with diagnosis.
Environment: Version 20.0 Update 10 (Build 1621 Alpha - AI 1.6.57) self-hosted
