Cuando conectas una app de terceros a MoveMentors vía OAuth (caso más común: un asistente IA vía MCP), otorgas scopes de permisos específicos. Este artículo lista cada scope y qué hace.
El modelo de scopes
MoveMentors OAuth sigue el modelo estándar OAuth 2.1 con PKCE. Autorizas a un cliente (ej. Claude), que recibe un token atado a scopes específicos. Cada request del cliente se valida contra esos scopes.
Si solo otorgas read:bookings, el cliente solo puede leer reservas; intentos de otras herramientas devuelven 403 Forbidden.
Otorgas scopes individuales en la pantalla de consent OAuth. Puedes revocar en cualquier momento.
Scopes de lectura
read:profile
Leer tu perfil de usuario (nombre, email, tipo de cuenta, ajustes).
Requerido por casi todo cliente. Permite que la IA sepa quién eres; sin esto no puede personalizar.
read:mentor
Leer tu perfil de mentor (bio, fotos, ubicaciones, certificaciones).
Para cuentas de mentor.
read:studio
Leer tu perfil de studio.
Para cuentas de studio.
read:classes
Leer las clases que organizas (título, agenda, capacidad, precio, etc).
read:bookings
Leer tus reservas (como anfitrión y como estudiante).
read:clients
Leer tu CRM de clientes (quién reservó, su historial, tus notas).
read:financials
Leer tu dashboard de ingresos y gastos. Feature Pro+.
read:reviews
Leer reviews en tu perfil y los que has dejado.
read:messages
Leer tu inbox (inquiries, mensajes de mentor).
read:public
Buscar el directorio público (mentores, studios, clases). Cualquiera puede sin auth, pero como scope autenticado devuelve data un poco enriquecida (ej. distancia desde tu ubicación guardada).
Scopes de escritura
write:profile
Actualizar tu perfil de usuario (nombre, ajustes).
write:mentor / write:studio
Actualizar tu perfil de mentor o studio.
write:classes
Crear, actualizar, borrar tus clases. Modificar agendas, capacidad, precios.
Feature Pro+; cuentas free que otorgan este scope igual no pueden hacer cambios (la herramienta devuelve "upgrade required").
write:bookings
Crear nuevas reservas (a nombre de un estudiante), cancelar reservas, marcar pagado.
Nota: las reservas tienen constraints. No puedes crear una reserva en clase agotada vía API más de lo que puedes vía UI.
write:clients
Actualizar notas y tags de clientes.
write:financials
Crear, actualizar, borrar gastos. Modificar categorización de ingresos. Feature Pro+.
write:reviews
Responder a reviews en tu perfil.
write:messages
Enviar mensajes (inquiries, respuestas, outreach de mentor).
Scopes especiales
mcp:tools
Permitir al cliente llamar herramientas MCP. Requerido para servidores MCP; sin esto el endpoint MCP rechaza requests.
offline_access
Permitir al cliente refrescar su access token sin re-autorización. Scope OAuth estándar; sin esto, el cliente tiene que re-auth cada vez que el token expira (~1 hora).
La mayoría pide esto para que el user no re-auth constante.
Bundles comunes
La mayoría de clientes piden un bundle sensato en lugar de cada scope. Típicos:
- Read-only:
read:profile,read:bookings,read:classes,read:clients. Útil para "muéstrame mi agenda". - Asistente personal: read-only más
write:bookings,write:classes,write:messages. El asistente gestiona operaciones. - Full control: todo menos
write:financials. Para power users.
Puedes deseleccionar scopes en consent; el cliente se adapta (algunas herramientas no disponibles, el resto funciona).
Qué puedo hacer en el consent
La pantalla de consent OAuth muestra:
- Nombre del cliente (ej. "Claude Desktop").
- Sitio del cliente (si lo da).
- Cada scope que pide.
- Un checkbox por scope (algunos pre-marcados como requeridos).
Puedes:
- Aprobar todo (default fácil).
- Deseleccionar scopes específicos y aprobar el subset.
- Negar todo.
Revocar acceso
/settings/connected-apps muestra cada cliente OAuth conectado a tu cuenta. Por cada uno:
- Nombre del cliente.
- Cuándo se autorizó.
- Qué scopes tiene.
- Timestamp de último uso.
- Botón "Revocar".
Pulsa Revocar e invalidamos el token. El cliente pierde acceso inmediato. Si re-autorizas el mismo cliente después, empiezas de cero; sin scopes "recordados".
Audit logging
Cada request OAuth se loggea en tu audit log en /settings/audit-log. Visible:
- Qué cliente hizo el request.
- Qué herramienta se llamó.
- Argumentos (con valores sensibles redactados).
- Estado de respuesta.
Útil cuando quieres saber qué ha hecho un asistente IA en tu nombre.
Qué los scopes no cubren
Cosas que los scopes NO permiten, sin importar el grant:
- Leer data privada de otros usuarios. Con scopes completos, un cliente solo accede a TU data y data pública de otros.
- Disparar payouts o modificar settings Stripe. Eso está en Stripe, no en nosotros.
- Modificar ajustes de cuenta que requieren confirmación por email (cambiar email, etc).
Intencional. Algunas acciones son demasiado de alto riesgo para delegar.
Preguntas frecuentes
¿Un cliente puede pedir un scope que no otorgué? El cliente recibe 403 en cualquier herramienta que requiera scope no otorgado. No pueden escalar.
¿Puedo ver qué hizo un cliente viejo si lo revoqué? Sí. El audit log preserva requests pasados incluso de clientes revocados.
¿Múltiples clientes pueden conectarse con scopes overlap? Sí. Cada cliente conectado tiene su token. Puedes tener Claude con acceso full Y ChatGPT read-only.
¿Hay forma de scope por clase o por cliente (más granular que scopes)? No actualmente. Scopes son la frontera; no soportamos "read bookings solo de clase X" o ACLs finos. Podríamos agregar si hay demanda.
¿Por qué no hay scope delete:account?
Borrar cuenta requiere confirmación por email. No se puede vía OAuth, ni con scopes completos.
Próximos pasos
- Servidor MCP: el consumidor principal de OAuth.
- Apps conectadas: gestionar autorizaciones.