Guides

Kanban Studio MCP

Legacy API key fallback

Only use this if your MCP client cannot complete OAuth.

Author: Ethan Navarro (Dev). Reviewed by the Kanban Studio team.

When to use this

OAuth is the default authentication model for Kanban Studio MCP. API keys are a compatibility fallback for legacy clients.

Use this route only when your client stack cannot support OAuth redirect or device flows. If OAuth is available, migrate to OAuth first to keep revocation and authorization controls centralized.

Steps

  1. Open Profile -> API keys and create a scoped key.
  2. Configure your MCP client with Authorization: Bearer mcp_live_...
  3. Rotate or revoke keys regularly.

Open API keys in Profile

Recommended scope baseline: start with read-only tools, validate board-level behavior in staging, then grant write scopes only to automations that require mutations.

Operational checklist: document owner, expiration policy, and rotation cadence per integration. This prevents abandoned keys from persisting after team changes.

Reference: review OAuth 2.0 security best current practices from the IETF to plan migration away from static credentials. OAuth 2.0 Security BCP.

Risk controls

Legacy API keys are static bearer credentials, so their operational risk is higher than OAuth tokens with centralized revocation and consent screens.

  • Store keys only in secret managers, never in shared docs or chat threads.
  • Use least privilege scopes and isolate keys per integration, board, and environment.
  • Set a fixed rotation window and enforce immediate revocation for compromised credentials.

Migration path to OAuth

Treat API keys as a temporary compatibility bridge. Plan migration in phases so each integration exits static credentials without disrupting production workflows.

  1. Inventory all current key-based clients and classify them by business criticality.
  2. Enable OAuth in staging, validate tools and board permissions, and compare behavior side by side.
  3. Cut over low-risk integrations first, then retire keys in high-impact systems with rollback safeguards.

Success criteria for migration: all production integrations authenticate with OAuth, no static key remains in active CI/CD pipelines, and revocation drills are tested at least once per quarter.

If a vendor tool cannot migrate yet, keep it in a dedicated risk register with owner, sunset date, and compensating controls. This prevents legacy access from becoming permanent technical debt.