Slab5

MCP authentication

MCP clients can authenticate with static workspace tokens or hosted OAuth. Static tokens keep quickstarts, controlled workspace testing, CI, and service agents simple. OAuth is the preferred hosted and enterprise path for delegated access, SSO/MFA-backed users, and stricter workspace policy.

For the account-created personal workspace path, see Personal workspace lifecycle.

Auth methods

Slab5 supports two MCP auth methods:

  • Static workspace tokens for quickstarts, controlled workspace testing, CI, and service agents.
  • Hosted OAuth for delegated human access, team workspaces, and enterprise security policy.

Both auth methods resolve to the same Slab5 tenant and workspace context before a tool runs. Scopes, module enablement, plan limits, audit events, and usage events apply either way.

Clients, grants, and scopes

An MCP client is whatever connects to Slab5 over MCP: ChatGPT, Claude, Cursor, a local script, or a service agent.

For static tokens, you can create multiple MCP clients in one workspace from the MCP Clients page by clicking New static token repeatedly. Each token gets its own name, secret, and selected scopes.

Example MCP clients
ChatGPT Support Assistant: support:read, support:write
Website CMS Publisher: cms:read, cms:write, assets:write
Analytics Reader: analytics:read, bi:read

That lets you revoke or narrow one integration without affecting the others.

A scope is a permission like assets:read or crm:write. It answers: "What app area and action is allowed?"

A grant is an authorization record for a subject. In MCP OAuth, the client signs in a user or subject, and the grant says: "This OAuth subject is allowed into this workspace with these scopes."

  • Grant = who is allowed.
  • Scopes = what that allowed identity can do.

Bearer tokens

Remote MCP configjson
{
  : var(--shiki-token-string)">"color: var(--shiki-token-parameter)">: var(--shiki-token-string)">"mcpServers": {
    : var(--shiki-token-string)">"color: var(--shiki-token-parameter)">: var(--shiki-token-string)">"slab5": {
      : var(--shiki-token-string)">"color: var(--shiki-token-parameter)">: var(--shiki-token-string)">"url": : var(--shiki-token-string)">"https://mcp.slab5.com/v1",
      : var(--shiki-token-string)">"color: var(--shiki-token-parameter)">: var(--shiki-token-string)">"headers": {
        : var(--shiki-token-string)">"color: var(--shiki-token-parameter)">: var(--shiki-token-string)">"Authorization": : var(--shiki-token-string)">"Bearer YOUR_SLAB5_TOKEN"
      }
    }
  }
}

OAuth connections

Hosted MCP clients should use OAuth when they need delegated user access, team policy, SSO, MFA, or enterprise controls. OAuth connections still require active Slab5 workspace membership before any app-plane operation executes.

The MCP gateway verifies OAuth access tokens against the configured issuer. It resolves the token subject to a Slab5 user, resolves the selected account when present, and then resolves an active workspace membership before scopes and module checks run.

OAuth requests can select a workspace with workspace_id or workspace_slug query parameters. Header-based selection with x-slab5-workspace-id or x-slab5-workspace-slug is also supported for clients that can send custom headers. If no workspace selector is provided, Slab5 uses the first active workspace membership for the authenticated user in the selected account.

MCP clients that support OAuth discovery can use:

  • /.well-known/oauth-protected-resource
  • /.well-known/oauth-authorization-server
  • /v1/.well-known/oauth-protected-resource
  • /v1/.well-known/oauth-authorization-server

When a request to the MCP endpoint is missing authorization, the gateway returns a WWW-Authenticate challenge with the protected-resource metadata URL.

OAuth workspace grants

Workspace owners and admins can add explicit OAuth workspace grants from the MCP Clients page. A grant is attached to one OAuth subject and one Slab5 workspace.

OAuth grants are a narrowing layer, not an elevation layer. The effective MCP OAuth scopes are:

workspace role scopes
intersect OAuth workspace grant scopes when a grant exists
intersect OAuth token permissions when present

If the OAuth token does not include a permissions list, Slab5 uses the allowed scopes from the workspace role and explicit grant. If no explicit OAuth workspace grant exists for the subject, Slab5 preserves the workspace role behavior so existing OAuth connections continue to work.

Use explicit grants when an OAuth-connected client should have less access than the signed-in user has in the Slab5 workspace. For example, an admin can keep normal admin access in the console while granting ChatGPT only crm:read and tasks:write through MCP.

Workspace-scoped URLs

OAuth-capable clients can use a workspace-scoped MCP server URL:

MCP OAuth server URL
https://mcp.slab5.com/v1?workspace_id=wrk_...

The protected-resource metadata URL keeps the same /v1 base path and workspace selector:

Protected resource metadata URL
https://mcp.slab5.com/v1/.well-known/oauth-protected-resource?workspace_id=wrk_...

Query parameters are used only for workspace routing. Do not put secrets in MCP server URLs.

Admin console lifecycle

Workspace owners and admins can create and revoke static MCP client tokens in the Slab5 console:

  • Create a workspace MCP client with a name and scope set.
  • Add, update, and revoke OAuth workspace grants for OAuth subjects.
  • Show the full token once after creation.
  • Store only the token prefix and hash.
  • List clients by name, client ID, prefix, status, timestamps, and scopes.
  • Revoke active clients after explicit confirmation.
  • Record create and revoke actions in audit logs and usage metering.

Members and readonly users cannot create or revoke static MCP client tokens. Credential actions are checked against active membership in the target workspace.

Workspace policy

Workspace admins can choose which MCP auth methods are allowed:

  • static_token: static MCP client tokens can be created and used.
  • oauth: static MCP client token creation and token use are blocked. MCP access must use hosted OAuth.
  • both: static tokens are allowed and hosted OAuth can also be supported.

Personal workspaces are constrained to static tokens. Team workspaces can choose static tokens, OAuth, or both. Static token creation and gateway authentication are blocked immediately when a workspace is set to OAuth-only.

For the quickstart workflow, create a token with:

Quickstart scopes
crm:read
crm:write
tasks:read
tasks:write
activity:read
activity:write

Add cms:read, cms:write, analytics:read, and analytics:write for content operations or analytics governance workflows. Use audit:read only for tools or UI flows that inspect audit logs.

Environment example

For local apps or graph runtimes, keep the token in environment variables and interpolate it into the MCP client configuration at runtime:

.env.localbash
SLAB5_MCP_URL=https://mcp.slab5.com/v1
SLAB5_WORKSPACE_TOKEN=slab5_workspace_token_with_mcp_scopes

For hosted OAuth, configure the API gateway with the AuthKit issuer and MCP resource metadata URLs:

API OAuth environmentbash
SLAB5_AUTHKIT_ISSUER=https://your-subdomain.authkit.app
SLAB5_MCP_RESOURCE_URL=https://mcp.slab5.com/v1
SLAB5_MCP_PROTECTED_RESOURCE_METADATA_URL=https://mcp.slab5.com/v1/.well-known/oauth-protected-resource

Token rules

  • Tokens are scoped to exactly one workspace.
  • Tokens should carry only the scopes needed by the workflow.
  • Tokens should be revocable from the admin console.
  • Tokens must not expose secrets in structured errors, logs, or docs examples.
  • Every tool call should record token/workspace context in audit and usage events.

For token creation, rotation, storage, and revocation guidance, see Credential lifecycle.

Was this page helpful?