Skip to main content
The Didit MCP authenticates with Log in with Didit (OAuth 2.1). It acts as a Didit user with your console role’s permissions — there is no API-key mode.

​
Log in with Didit

The hosted server (https://mcp.didit.me/mcp) is an OAuth 2.1 resource server. The Didit Business Console (business.didit.me) is the authorization server that hosts the consent screen and issues tokens. Your MCP client drives the standard flow automatically:
1

Discover

The client connects, gets a 401 with the protected-resource metadata, and discovers the authorization server.
2

Authorize (PKCE)

The client opens business.didit.me/authorize with a PKCE challenge. You sign in (or register) and see exactly which permissions are requested.
3

Consent

You approve. The console mints a separate session for that app — bound to the app and to the scopes you approved — and returns an authorization code, which the client exchanges for that session’s access token (and a refresh token).
4

Call tools

The client sends the access token with every request. The MCP validates it and acts as you.
Clients that support Dynamic Client Registration (RFC 7591) register themselves automatically — there is nothing to pre-provision on your side. This covers both local clients using a loopback or native callback (Cursor, Windsurf, Gemini CLI, MCP Inspector) and cloud-hosted clients using one of Didit’s reviewed callback URLs (Claude, ChatGPT, Grok, VS Code for the Web, Docker MCP Gateway, Mistral, Cloudflare). An unreviewed remote callback is refused with invalid_redirect_uri — that client needs an operator to register it first.

​
Scopes

The connector requests two coarse scopes, shown in plain language on the consent screen: The scopes you approve are carried on the token and enforced server-side, so an app connected with didit:verification alone is refused on the management surface even when your own role would allow it. A connection that requests no scope gets identity only (openid profile email): it can tell who you are and nothing else. An app’s effective permissions are the intersection of the approved scopes and your console role — never the wider of the two. An MCP token also never carries staff privileges, even when the underlying account has them.

​
Multi-organization & roles

The hosted token represents you, so the agent can work across every organization you belong to in a single connection — cross-app tools (didit_session_search, didit_analytics, didit_context_get) aggregate over all of them automatically. Your role is always enforced server-side. A READER can list and read but write calls return a permission error; an OWNER/ADMIN can write. The MCP never grants more than your console role already allows.

​
Token lifetime

An approved app gets its own session, separate from the browser session you approved it from. Access tokens last 24 hours and the client silently refreshes them with the refresh token, which keeps the app’s scopes and stays bound to that app. If a refresh fails (for example after you disconnect the app), the client re-runs Log in with Didit on the next call. Because the app’s session is its own, signing out of the console — or logging a device out under Active sessions — leaves connected apps working, and disconnecting an app never signs you out anywhere.

​
Disconnecting an app

1

From the console

Settings → Authentication → Connected apps lists every app you have approved, with its registered name and the permissions it was granted. Disconnect ends that app’s access immediately: both its access token and its refresh token stop working, and nothing else is affected.
2

From the app (RFC 7009)

A client can hand its own access back by posting the token to the authorization server’s revocation_endpoint, advertised at https://business.didit.me/.well-known/oauth-authorization-server. As RFC 7009 requires, a successful call answers 200 whether or not the token was still live — so the response never tells you whether a token was valid.A 503 means the revocation could not be applied: treat the token as still valid and retry. Anything else (400) is a malformed request or an unregistered client_id, and retrying will not help.
Why no API key? Every MCP tool calls the user-scoped console endpoints (/organization/{org}/application/{app}/…), which authorize a Bearer token with per-role privileges and reject x-api-key. An application API key is for calling the REST API directly from your own backend (e.g. creating sessions) — not for this MCP. Tools like didit_org_reveal_application_api_key manage those REST keys; they are not how the MCP itself authenticates.

​
Auth failures

A 403 means re-authenticate — reconnect / re-run Log in with Didit:
A 403 on a specific tool usually means either your role lacks that permission (e.g. a READER attempting a write) or the connection was approved without the scope that tool needs — not that the whole connection is broken. Reconnecting and approving both scopes fixes the second case; the first needs a role change. If every tool fails, check Settings → Authentication → Connected apps in the console: an app that was disconnected there has to be approved again.

Tools reference

What each tool does and which are write/destructive.

Advanced

Scopes, cross-app behavior, and self-hosting.