HockeyStick Knowledge Base Knowledge Base Open Command Centre

MCP server and AI apps

Auth0 and onboarding a new AI client

How sign-in works, static client IDs versus CIMD, and what engineering sets up before a new AI app can connect.

Auth0 and onboarding a new AI client

Sign-in for AI apps runs through Auth0. You do not configure Auth0 yourself, but you need to know how it works so you can tell a client what to expect and brief engineering when someone asks for a new app.

The sign-in

  1. The AI app sends the user to Auth0 with HockeyStick's MCP resource and the scopes it wants.
  2. The user enters their email address and the email code. Only the passwordless email connection is accepted. A password or Google login gives a different identity, and the MCP refuses it.
  3. The consent screen lists the access being requested, including write access when hsai.write is asked for.
  4. The app receives a short-lived MCP token (five minutes) plus a refresh grant, and refreshes in the background.

Two ways an app identifies itself

Static client IDs. Engineering creates one public native Auth0 application per app, with an exact callback. Codex and Claude Code use static IDs because Auth0 matches local callback ports exactly, so each needs a pinned port (Codex 6279, Claude Code 6278).

Client ID Metadata Documents (CIMD). The app presents a published metadata URL instead of an ID. claude.ai and Claude Desktop use Claude's published identity, so users only paste the server URL. Auth0 imports that URL once as an application. Open Dynamic Client Registration is switched off on Test, so unknown apps cannot register themselves. An app that is not admitted gets "client is not authorized to access MCP resource server".

What engineering sets up for a new AI app

When a client asks to use an app that is not on the supported list, raise it with engineering. Onboarding an app means, per environment:

  • Creating or importing the Auth0 application, with consent required, PKCE, no secret and the exact callback.
  • Granting it user access to that environment's MCP resource with the approved scopes only.
  • Adding it to the email connection and to the guard Action's allowed list.
  • Adding its ID or metadata URL to the environment's MCP_CLIENT_IDS admission list and reopening MCP.
  • A live sign-in, read, write denial for read-only tokens, and an audit check.

Until all of that is done, the app cannot connect, however it is configured on the user's side.

Shared IDs and audit

Codex and older hosted Claude connectors share one static ID, so audit cannot tell them apart. Claude Code and CIMD-based claude.ai connections are distinguishable.