How AI tools authenticate to StackJack

Every AI tool talks to the same endpoint (https://mcp.stackjack.io/mcp), but there are three ways it can prove who it is. This page helps you pick the right one and explains what happens behind the scenes.

The three methods at a glance

A credential only works in its own lane: an API key cannot be used for Basic authentication, and a Client ID + Secret cannot be sent as an API key.

Method 1: Sign in with StackJack (recommended)

This is the URL-only path. You paste the endpoint URL into your AI tool and the rest is automatic:

1. The tool contacts the endpoint and is told, per the OAuth standard, where to sign in.
2. The tool registers itself with StackJack automatically (no manual credential creation).
3. A browser window opens on the StackJack sign-in page — sign in with your normal portal account.
4. The tool is now connected as you: it can use exactly the tools you have been assigned, and its activity is attributed to you in usage logs.

There is nothing to copy, nothing to store, and nothing to rotate. Access follows your team membership — if an admin removes you from the team, every AI tool you connected this way stops working on its next request.

Two flavors you may encounter: per-install and shared-app sign-in

You do not choose between these — the AI product does — but you may notice the difference:

• Per-install registration (DCR). Most tools register a unique, private identity for your specific installation (this is OAuth Dynamic Client Registration). These connections appear as read-only AI sessions after their first tool call — in your own Your AI connections view on the MCP Setup page, and, for admins, under each member's row on the Team page.
• Shared-app identity (CIMD). Some AI products identify themselves with a single published URL shared by every user of that product (Client ID Metadata Documents). Because the identity is shared, StackJack records an individual authorization for each team member who signs in through it. Admins manage those authorizations per member on the Team page (expand the member's row → Connected apps → Revoke); each user also sees their own in the read-only Your AI connections view on the MCP Setup page — see Connected Apps.

The consent screen (shared apps only)

When you sign in through a shared-app (CIMD) tool, StackJack shows a branded consent screen after sign-in and before the connection completes — every time that app signs you in, not just the first. It is headed "Authorize <app name>" and explains, in one line, that the app will connect to your StackJack organization and use its MCP tools on your behalf. A small diagram shows the app on one side and your StackJack organization on the other.

Below that is a "Verify before you approve" panel — the part worth reading before you click:

• App identity (client_id) — the full URL the app identifies itself with. Confirm it belongs to the AI product you expect.
• Your authorization will be sent to — the host your sign-in result is delivered to. Confirm it matches the app, or is your own machine for a desktop/CLI tool.

If the authorization is being delivered to software on your own computer, the screen adds a local application warning telling you to continue only if you started the sign-in yourself — normal for desktop and CLI tools.

Choose Allow access to finish connecting or Deny to cancel. Denying returns you to the AI tool with an "access denied" result and grants nothing. The screen also reminds you that this access can be revoked at any time — an admin does that per member on the Team page; see Connected Apps.

First-time users without an invite

If you sign in through an AI tool using a company identity that is not yet a member of the StackJack workspace, the connection still completes — but in a pending approval state with almost no tools until an admin approves you. See Approving self-registered members.

Method 2: Client ID + Secret (Basic authentication)

For tools that cannot open a browser, an admin creates an MCP client on the MCP Setup page and gives you a Client ID and a secret. The tool sends them on every request as a standard HTTP Basic header:

Authorization: Basic <base64 of CLIENT_ID:CLIENT_SECRET>

The same credentials also work as an OAuth client_credentials grant for tools that prefer a token flow, and a tool presenting them through the OAuth flow is approved instantly, without an interactive sign-in.

The secret is shown once at creation and cannot be retrieved later — see Managing MCP credentials.

Method 3: API key (sjk_…)

For automation platforms that support neither browser sign-in nor Basic auth, an admin can create a single-value API key that starts with sjk_. It works in either of two header forms:

X-API-Key: sjk_...

Authorization: Bearer sjk_...

Creating an API key requires typing an explicit risk acknowledgment, because a single-value key is easier to leak than the other methods. Treat it like a password: store it in your platform's credential vault or environment variables, never in source control, and prefer Sign in with StackJack for interactive AI tools.

Session lifetimes (sign-in method)

• A signed-in connection uses short-lived access tokens (1 hour) that the tool refreshes automatically in the background — you will not be asked to sign in again while the tool is in regular use.
• An idle connection expires after 30 days without use; the tool will prompt you to sign in again.
• Revocation (by an admin) does not wait for tokens to expire — every request is re-checked, so revoked access stops on the very next request. See OIDC sessions and revoking AI access.