OAuth and CIMD

Professional

Algo Trade Analytics’s recommended MCP auth path is OAuth with metadata discovery. Capable clients should discover Algo Trade Analytics’s OAuth metadata from the MCP endpoint and use the MCP URL as the access-token resource audience.

This avoids the fragile setup that caused early failures: pasted bearer tokens, fixed Auth0 application client IDs, or pre-listed local callback URLs.

CIMD solves client identity and keeps the public client identifier separate from the MCP resource audience. With Auth0, CIMD registration is manual: a tenant administrator imports the document once, then grants that third-party application access to the MCP API. CIMD does not control how a local MCP client stores access tokens or refresh tokens after login.

Terms

Term	Meaning
MCP endpoint	The remote HTTP MCP URL copied from Algo Trade Analytics, such as a preview or production /mcp URL.
Resource audience	The API/resource the access token is for. For Algo Trade Analytics MCP, this is the MCP endpoint URL.
Protected-resource metadata	Metadata published by Algo Trade Analytics so clients can discover how to authenticate to the MCP resource.
Client ID Metadata Document (CIMD)	An HTTPS client_id document that describes an MCP client to Auth0. Auth0 requires an administrator to import it before login.
Dynamic Client Registration (DCR)	An optional fallback registration mechanism. It is not the primary Algo Trade Analytics setup.
Callback URL	The URI where the OAuth authorization response returns. Auth0 validates it against the callbacks imported from the CIMD.

Expected OAuth Flow

1. The MCP client is configured with the Algo Trade Analytics MCP endpoint.

2. The client discovers protected-resource metadata from Algo Trade Analytics.

3. The client uses Algo Trade Analytics’s resource metadata to identify the authorization server and supported scopes.

4. The client presents the HTTPS CIMD URL as its client_id.

5. Auth0 resolves the CIMD client that a tenant administrator imported earlier.

6. The client starts a PKCE authorization-code login with the MCP URL as the resource audience and requests offline_access for refresh-token issuance.

7. Algo Trade Analytics receives access tokens scoped to MCP and bound to the Algo Trade Analytics account that completed sign-in.

What Not To Do

• Do not paste a bearer token when the client supports OAuth.
• Do not pass a fixed Auth0 application client ID (an opaque value like aBc123…). Pass the CIMD URL instead: --oauth-client-id for Codex, --client-id for Claude Code. Omitting the client identifier entirely does not fall back to Algo Trade Analytics — the client sends its own identity and the authorization server answers Unknown client.
• Do not confuse the CIMD URL with the MCP resource audience.
• Do not accumulate one-off local callback URLs. For Codex, set the top-level mcp_oauth_callback_port = 5555 setting and use the complete callback published by the environment-specific CIMD. For Claude Code, pass --callback-port 5555 so it uses the published http://localhost:5555/callback.
• Do not wrap the MCP URL in Markdown brackets.
• Do not use the preview endpoint as the production endpoint, or production as preview. Copy the value from the MCP Access page for the current environment.

Auth0 Requirements

Algo Trade Analytics OAuth/CIMD depends on these authorization-server settings:

Requirement	Why it matters
Client ID Metadata Document Registration	Advertises CIMD support and allows the tenant administrator to import the HTTPS metadata document.
Manual CIMD import	Registers the CIMD URL as a strict third-party Auth0 application before the first user login.
User-delegated API grant	Authorizes the imported CIMD client to request the Algo Trade Analytics MCP scopes.
Resource Parameter Compatibility Profile	Keeps the MCP endpoint URL as the access-token audience.
Refresh token support	Keeps long-running MCP research jobs alive after the short-lived access token expires. The Authorization Server must advertise refresh_token and allow offline_access.
Supported MCP scopes	Allows mcp:read, mcp:research:write, mcp:candidate:write, and mcp:memory:write to be requested.

Client Credential Storage

Long research sessions require two separate pieces to work:

• the authorization server must issue refresh tokens, and
• the MCP client must cache and refresh those credentials without repeatedly asking the user.

For Codex on macOS, repeated prompts for Codex MCP Credentials after clicking Always Allow point to local Keychain access behavior, not to a bad CIMD document. Use Codex’s file-backed MCP OAuth credential store or the manual bearer fallback on machines where Keychain prompts make OAuth unusable.

Note

If OAuth works after a retry without any client-side configuration change, the first failure was usually metadata propagation, an Auth0-side issue, or a transient service/browser-profile mismatch. The setup should still stay on the CIMD path.

Why CIMD Helps

CIMD gives MCP clients a stable, HTTPS-hosted identity without creating one Auth0 client per connection. Auth0 still requires an administrator to import the document and configure its API access policy.

The result is a cleaner OAuth setup:

• no copied bearer token,
• no stored static client per local agent,
• no DCR client buildup,
• one reviewed callback policy in the CIMD,
• resource-audience tokens for the MCP endpoint.

Related

Client Setup Use the OAuth path in Codex, Claude, Cursor, ChatGPT, and fallback clients

Troubleshooting OAuth errors, wrong browser profile, missing tools, and revoked connections