Guides

Kanban Studio MCP

Fallback legacy con API key

Usa esto solo si tu cliente MCP no puede completar OAuth.

Autor: Ethan Navarro (Dev). Revisado por el equipo de Kanban Studio.

Cuando usar esto

OAuth es el modelo de autenticacion por defecto para Kanban Studio MCP. Las API keys quedan como fallback de compatibilidad para clientes legacy.

Usa esta ruta solo cuando tu stack de cliente no soporte OAuth con redirect o device flows. Si OAuth esta disponible, migra primero para mantener controles centralizados de revocacion y autorizacion.

Pasos

  1. Abre Profile -> API keys y crea una key con scopes minimos.
  2. Configura tu cliente MCP con Authorization: Bearer mcp_live_...
  3. Rota o revoca keys periodicamente.

Abrir API keys en Profile

Baseline recomendado de scopes: empieza con herramientas de lectura, valida comportamiento por tablero en staging y solo despues concede scopes de escritura a automatizaciones que realmente mutan datos.

Checklist operativo: documenta propietario, politica de expiracion y frecuencia de rotacion por integracion. Esto evita que queden keys abandonadas cuando cambian los equipos.

Referencia: revisa las recomendaciones actuales de seguridad OAuth 2.0 del IETF para planificar la salida de credenciales estaticas. OAuth 2.0 Security BCP.

Controles de riesgo

Las API keys legacy son credenciales bearer estaticas, por lo que su riesgo operativo es mayor que el de tokens OAuth con revocacion centralizada y pantallas de consentimiento.

  • Guarda keys solo en gestores de secretos, nunca en documentos compartidos o chats.
  • Aplica minimo privilegio e identifica keys por integracion, tablero y entorno.
  • Define ventana fija de rotacion y revocacion inmediata ante cualquier compromiso.

Ruta de migracion a OAuth

Trata las API keys como un puente temporal de compatibilidad. Planifica la migracion por fases para salir de credenciales estaticas sin interrumpir flujos en produccion.

  1. Inventaria clientes que usan key y clasificalos por criticidad de negocio.
  2. Activa OAuth en staging, valida tools y permisos por tablero, y compara comportamiento en paralelo.
  3. Migra primero integraciones de bajo riesgo y retira keys en sistemas criticos con salvaguardas de rollback.

Criterio de exito de migracion: todas las integraciones de produccion autentican con OAuth, no quedan keys estaticas en pipelines activos y los simulacros de revocacion se prueban al menos una vez por trimestre.

Si una herramienta de proveedor no puede migrar todavia, mantenla en un registro de riesgo dedicado con responsable, fecha de retirada y controles compensatorios. Esto evita que el acceso legacy se convierta en deuda tecnica permanente.