Integración LTI Moodle: guía práctica para conectar herramientas externas

Integración LTI Moodle: qué problema resuelve realmente

El problema real no es técnico. Es organizativo.

Una universidad tiene Moodle como LMS. También tiene una herramienta de evaluación externa, un simulador de laboratorio, un sistema de videoconferencia y, probablemente, una herramienta de flashcards o guías de estudio que quiere integrar para que los alumnos no tengan que gestionar otra cuenta.

Sin LTI, cada integración es artesanal: SSO a medida, sincronización manual de notas, lógica de roles duplicada y una dependencia frágil entre sistemas que ningún desarrollador quiere tocar seis meses después. En cambio, una integración LTI Moodle define un contrato estándar entre Moodle y la herramienta externa.

LTI, Learning Tools Interoperability, es el estándar que define cómo un LMS y una herramienta externa se presentan, autentican y se intercambian datos de forma estructurada. No es magia: es un contrato técnico bien definido.

Moodle actúa como Platform. La herramienta externa actúa como Tool. Cuando un alumno hace clic en una actividad LTI dentro de Moodle, el LMS le dice a la herramienta: «este usuario es alumno, pertenece a este curso, aquí tienes su identificador, ya puedes dejarle pasar». Además, si la herramienta devuelve una nota, Moodle puede registrarla directamente en el gradebook.

Por tanto, lo que parece un simple clic implica resolver autenticación, autorización, contexto, privacidad y retorno de calificaciones. Todo a la vez. Moodle Docs resume esta idea al explicar que las herramientas LTI permiten acceder a aplicaciones externas desde el curso sin que el estudiante tenga que salir del curso ni iniciar sesión en otro sistema.

Moodle como Platform y Moodle como Tool

En la mayoría de proyectos, Moodle actúa como Platform: el usuario entra en Moodle y desde ahí lanza una herramienta externa. Es el escenario habitual cuando se integran simuladores, herramientas de evaluación, flashcards, repositorios de contenidos, dashboards o aplicaciones SaaS educativas.

Sin embargo, Moodle también puede actuar como Tool, publicando contenidos o actividades para que otra plataforma compatible con LTI los consuma. Esta distinción es importante en ecosistemas con varios campus, consorcios universitarios, plataformas corporativas o repositorios de contenidos compartidos.

No es lo mismo integrar una herramienta externa dentro de Moodle que exponer Moodle como proveedor de contenidos hacia otro LMS. En el primer caso, Moodle gobierna el lanzamiento. En el segundo, Moodle se comporta como una herramienta externa dentro de otra plataforma.

Integración LTI Moodle con LTI 1.1 vs LTI 1.3

Si estás empezando una integración nueva, esta sección debería ahorrarte semanas de trabajo en el futuro.

LTI 1.1 se basa en OAuth 1.0a. El LMS firma la petición con una clave compartida, formada por consumer_key y consumer_secret, y la herramienta valida esa firma. Es simple, pero tiene problemas estructurales: credenciales compartidas, rotación manual, extensiones irregulares y un modelo de seguridad heredado.

LTI 1.3, en cambio, reemplaza ese modelo con OAuth 2.0, OpenID Connect y JWT firmados con clave asimétrica. El Platform publica su JWK Set en una URL pública; la herramienta lo descarga y usa la clave pública para verificar los tokens. Así, ningún secreto compartido viaja en los mensajes.

Además, 1EdTech ha dejado claro que las versiones legacy de LTI no deben ser la base de nuevas integraciones. Por eso, si vas a diseñar una integración LTI Moodle hoy, la decisión razonable es trabajar con LTI 1.3 y LTI Advantage.

Flujo de lanzamiento LTI 1.3 en tres pasos

1. Moodle → Tool: OIDC Login Initiation
   POST /lti/login
   { iss, login_hint, target_link_uri, lti_message_hint }

2. Tool → Moodle: Authorization Request
   GET /mod/lti/auth.php?...
   redirect con state + nonce

3. Moodle → Tool: ID Token firmado
   POST /lti/launch
   { id_token: <JWT firmado con RSA> }

Dentro de ese JWT están los claims: identidad del usuario, contexto del curso, rol, configuración de Deep Linking, extensiones AGS/NRPS y cualquier dato custom que hayas configurado.

Arquitectura de una integración LTI Moodle moderna

Una integración LTI Moodle bien hecha implica más de un endpoint. De hecho, el error habitual es pensar que LTI es solo una URL de lanzamiento. En LTI 1.3, la herramienta externa debe exponer varios puntos de entrada y gestionar estado, claves, tenants y servicios.

Registro manual vs Dynamic Registration

En integraciones sencillas, registrar la herramienta manualmente en Moodle puede ser suficiente. Sin embargo, cuando la herramienta se ofrece como SaaS multi-tenant o debe conectarse a varias instituciones, conviene valorar LTI Dynamic Registration.

Este mecanismo permite automatizar parte del intercambio de configuración entre Moodle y la herramienta externa, reduciendo errores manuales en URLs, Client ID, JWKS, endpoints y servicios habilitados. No siempre compensa implementarlo desde el primer día, pero sí debería contemplarse en la arquitectura si el producto va a escalar a varios campus, clientes o plataformas LMS.

sequenceDiagram
    participant User as Alumno
    participant Moodle as Moodle Platform
    participant Tool as Herramienta externa

    User->>Moodle: Abre actividad LTI
    Moodle->>Tool: OIDC Login Initiation
    Tool->>Moodle: Authorization Request con state y nonce
    Moodle->>Tool: id_token JWT firmado
    Tool->>Tool: Valida iss, aud, nonce, deployment_id y firma
    Tool->>User: Crea sesión y muestra la herramienta
    Tool->>Moodle: Envía score vía AGS

Endpoints mínimos de la herramienta externa

/lti/login       → OIDC Login Initiation handler
/lti/launch      → Receptor del JWT y lanzamiento de sesión
/lti/deeplink    → Respuesta Deep Linking, si se implementa
/lti/jwks        → JWK Set público de la herramienta
/lti/callback    → Return URL para OAuth2, si necesitas tokens adicionales

En Moodle, la configuración del lado Platform define la URL del JWK Set, la URL de autenticación OIDC, el Client ID único por registro de herramienta y los servicios habilitados: AGS, NRPS, memberships o Deep Linking.

Un error frecuente es tratar el Client ID como un identificador global de herramienta. No lo es. En LTI 1.3, el Client ID es específico de cada registro. Por tanto, si registras la misma herramienta en dos instancias de Moodle distintas, tendrás dos Client IDs diferentes.

Por eso, una integración LTI Moodle debe diseñarse con multi-tenancy desde el primer día. Este enfoque encaja especialmente bien con arquitecturas Headless LMS, donde Moodle conserva su papel como sistema académico, pero la innovación de producto vive fuera del core.

Login, Deep Linking, AGS y NRPS en una integración LTI Moodle

LTI Advantage agrupa LTI 1.3 con servicios clave como Deep Linking, Assignment and Grade Services y Names and Role Provisioning Services. En la práctica, estos servicios convierten una integración básica en una integración útil para profesores, alumnos y administradores.

Scopes y principio de mínimo privilegio

No todas las herramientas LTI necesitan todos los servicios. Una herramienta que solo lanza contenido no necesita AGS. Una herramienta que no consulta participantes no debería solicitar NRPS. En producción, los scopes OAuth2 deben configurarse con el principio de mínimo privilegio.

OIDC Login Initiation

El primer paso del flujo. Moodle llama a tu endpoint /lti/login con un login_hint y un lti_message_hint. A continuación, tu herramienta responde redirigiendo al endpoint de autenticación de Moodle con un state y un nonce que debes guardar temporalmente.

El nonce es crítico para la seguridad. Sin validación de nonce, un atacante puede intentar reutilizar un token interceptado. Por tanto, guarda el nonce con TTL corto, idealmente diez minutos o menos, y elimínalo tras su primer uso.

Deep Linking

Deep Linking permite que el profesor seleccione qué contenido concreto quiere vincular desde Moodle. Por ejemplo, en una herramienta de flashcards, el docente puede elegir exactamente qué mazo de tarjetas quiere asociar a una actividad.

El flujo es inverso al lanzamiento normal: Moodle envía un LtiDeepLinkingRequest, la herramienta muestra una pantalla de selección, y después devuelve un LtiDeepLinkingResponse firmado con los items seleccionados.

AGS: Assignment and Grade Services

AGS permite a la herramienta devolver notas a Moodle. Se apoya en OAuth2 con client_credentials para obtener un access token y luego realizar llamadas REST a los endpoints de lineitem y scores de Moodle.

POST /mod/lti/services.php/{contextId}/lineitems
Authorization: Bearer <access_token>
Content-Type: application/vnd.ims.lis.v2.lineitem+json

{
  "scoreMaximum": 100,
  "label": "Práctica 1: Fundamentos",
  "resourceId": "deck-123"
}

Un punto que se suele pasar por alto: AGS diferencia entre lineitem, la columna del gradebook, y score, la nota de un alumno concreto. No necesitas recrear el lineitem en cada sesión.

NRPS: Names and Role Provisioning Services

NRPS permite a la herramienta consultar quién está matriculado en el curso y qué rol tiene. Esto resulta útil para sincronizar grupos, mostrar progreso comparativo o implementar lógica de rol sin depender únicamente del claim del JWT de lanzamiento.

GET /mod/lti/services.php/{contextId}/memberships
Authorization: Bearer <access_token>
Accept: application/vnd.ims.lti-nrps.v2.membershipcontainer+json

En productos con analítica, seguimiento de cohortes, trabajo por grupos o dashboards docentes, NRPS suele ser el servicio que convierte una integración básica en una integración verdaderamente útil. Eso sí: úsalo con criterio, minimizando los datos personales y documentando bien qué información se sincroniza.

Mapeo de roles LTI a permisos internos

Una herramienta LTI no debería asumir que los roles recibidos desde Moodle se corresponden automáticamente con sus permisos internos. Lo recomendable es crear una capa de mapeo entre roles LTI y roles propios de la aplicación.

Por ejemplo, un usuario con rol docente en Moodle puede necesitar permisos de edición completa en una herramienta, pero en otra institución quizá solo deba consultar analíticas. Por eso, en productos multi-tenant, el mapeo de roles debería ser configurable por cliente, tenant o deployment.

Coste, alcance y complejidad de una integración LTI Moodle

No todas las integraciones LTI tienen el mismo alcance. El error habitual es presupuestar una integración como si fuera solo un formulario de configuración, cuando en realidad puede implicar seguridad, multi-tenancy, gradebook, privacidad, soporte y operación en producción.

Por eso, antes de estimar una integración LTI Moodle conviene definir qué problema se quiere resolver: acceso único, selección de contenidos, retorno de notas, sincronización de participantes, soporte multi-institución o cumplimiento operativo. Cada capa añade valor, pero también aumenta la responsabilidad técnica.

Errores comunes que rompen una integración LTI Moodle

1. No validar el iss del JWT contra el registro esperado

El claim iss del token debe coincidir exactamente con el issuer del Platform registrado. Incluso una diferencia de trailing slash puede romper la validación o, peor todavía, abrir la puerta a aceptar tokens de un Platform incorrecto.

2. Usar el mismo par de claves RSA para todos los registros

Si tu herramienta sirve múltiples instancias de Moodle, cada registro debe tener su propio Client ID y configuración de deployment. Además, conviene valorar una estrategia de claves que facilite la rotación y el aislamiento por tenant. Compartir una configuración global sin control complica la rotación y reduce el aislamiento operativo.

3. No manejar correctamente el estado entre login initiation y launch

La petición de login y el posterior JWT de lanzamiento son dos requests HTTP distintos. Por eso, si tu aplicación es stateless o serverless, debes persistir el state y el nonce en Redis, base de datos u otro almacén externo.

4. Cachear el JWK Set de Moodle indefinidamente

Moodle puede rotar sus claves. Si cacheas el JWKS sin TTL y Moodle rota, todos los lanzamientos empezarán a fallar por error de firma. En consecuencia, implementa una caché con TTL razonable y una invalidación automática si la verificación falla.

5. Ignorar el claim deployment_id

En LTI 1.3, el par {iss, deployment_id} identifica un despliegue concreto dentro de un Platform. Una misma instancia de Moodle puede tener múltiples deployment IDs si has registrado la herramienta varias veces.

6. Enviar scores AGS sin verificar el lineitem

Antes de enviar una nota, comprueba que el lineitem existe y que el resourceId o tag coincide. De lo contrario, puedes crear columnas de notas duplicadas en el gradebook de Moodle.

7. No traducir los errores técnicos a mensajes operativos

En producción no basta con saber que “ha fallado el launch”. Conviene distinguir errores como invalid_signature, state_mismatch, nonce_already_used, jwt_expired, unknown_deployment, jwks_unavailable o ags_lineitem_not_found. Cada uno apunta a una causa distinta y debe generar logs accionables.

Qué ocurre al duplicar cursos o restaurar copias en Moodle

Una integración LTI Moodle no solo debe funcionar cuando se crea una actividad desde cero. También debe comportarse correctamente cuando un profesor duplica un curso, restaura una copia de seguridad o reutiliza actividades en una nueva edición académica.

En estos casos pueden aparecer problemas con enlaces que apuntan al mismo recurso externo, lineitems AGS duplicados, actividades Deep Linking reutilizadas o históricos de progreso mezclados entre cursos. Por tanto, la herramienta debe decidir si identifica el recurso por actividad, curso, deployment, contexto o una combinación de varios identificadores.

Este punto debe probarse antes de producción, especialmente en instituciones que reutilizan plantillas de cursos cada semestre o cada curso académico. En una integración madura, el comportamiento ante copia, backup y restore debe estar documentado para administradores Moodle y equipos de soporte.

Cookies, iframes y navegadores en integraciones LTI Moodle

Muchas integraciones LTI funcionan perfectamente en local y fallan al llegar a producción por un motivo aparentemente ajeno al estándar: el navegador. Cuando Moodle lanza una herramienta externa dentro de un iframe, la sesión de la herramienta puede depender de cookies consideradas de terceros.

Esto afecta especialmente a escenarios donde la herramienta está en un dominio distinto al Moodle. Chrome, Safari, Firefox y los navegadores móviles aplican políticas diferentes sobre cookies de terceros, tracking prevention y almacenamiento en iframes. Por tanto, la integración debe probarse en más de un navegador y no solo en el entorno de desarrollo.

• Usa cookies Secure y revisa SameSite=None si la herramienta se abre embebida en iframe.
• Permite una opción de apertura en ventana nueva cuando el iframe no sea fiable.
• No dependas únicamente de la cookie de sesión para completar el flujo OIDC; persiste state y nonce en servidor.
• Valida el comportamiento en Safari, especialmente en iPad y macOS, si la institución usa dispositivos Apple.
• Documenta qué dominios, cabeceras y políticas CSP necesita la herramienta para funcionar correctamente.

Si el lanzamiento se queda en blanco, se reinicia constantemente o pierde la sesión tras validar el JWT, el problema puede no estar en LTI, sino en cookies, cabeceras, iframe, CSP o configuración de dominio.

Caso real: integración LTI Moodle para Flashcards o Guide Wizard

Tomemos como ejemplo una herramienta de flashcards con IA generativa e integrémosla con Moodle usando LTI 1.3 completo. El patrón también aplica a herramientas como Guide Wizard, simuladores, sistemas de evaluación o dashboards externos.

Registro de la herramienta en Moodle

El profesor o administrador va a Administración del sitio → Plugins → Módulos de actividad → Herramienta externa → Gestionar herramientas y añade la herramienta. Puede introducir una URL de configuración o configurar manualmente la URL de lanzamiento, el JWK Set, la URL de login OIDC y el Client ID.

Después, activa los servicios necesarios: AGS para calificaciones, NRPS para membresías y Deep Linking si el profesor debe seleccionar contenido concreto desde Moodle.

Flujo del alumno

1. El alumno abre la actividad «Flashcards Tema 3» en el curso de Moodle.
2. Moodle inicia el OIDC login hacia /lti/login.
3. La herramienta redirige a Moodle para autorización.
4. Moodle envía el JWT firmado a /lti/launch.
5. La herramienta valida la firma con el JWK Set de Moodle.
6. La herramienta crea o recupera la sesión del alumno sin contraseña adicional.
7. El alumno practica las flashcards.
8. La herramienta registra su progreso.
9. Finalmente, envía la nota al lineitem AGS de Moodle.

Este flujo permite construir herramientas externas potentes sin convertir Moodle en un monolito. Por eso, tiene mucho sentido combinar integración LTI Moodle con una estrategia de arquitectura Headless LMS basada en LTI 1.3.

Privacidad y GDPR

En este flujo, Moodle no debería enviar más datos personales de los estrictamente necesarios. El identificador sub suele ser un identificador opaco proporcionado por la plataforma y debe tratarse como identificador técnico, no como dato legible de usuario. Si necesitas nombre, email o información de matrícula mediante NRPS, debes solicitarlo de forma explícita y documentarlo en el acuerdo de tratamiento de datos con la institución.

Integración LTI Moodle vs API REST vs plugin Moodle

Una buena arquitectura no consiste en usar LTI para todo, sino en elegir bien el mecanismo de integración. LTI resuelve muy bien el lanzamiento contextual de herramientas externas, pero no sustituye a los Web Services de Moodle ni a un plugin cuando se necesita modificar comportamiento interno.

En muchos proyectos reales se combinan varios enfoques: LTI para el acceso contextual, API REST para operaciones específicas, webhooks para automatización y plugin Moodle cuando hay que intervenir dentro del propio LMS.

Cuándo no usar LTI en Moodle

LTI no es la solución a todo. De hecho, hay escenarios donde una integración LTI Moodle introduce más complejidad de la que resuelve.

Cuando necesitas comunicación bidireccional en tiempo real

LTI es un protocolo de lanzamiento y de retorno de datos. Si tu herramienta necesita notificar eventos en tiempo real, como progreso continuo o alertas inmediatas, probablemente necesitas webhooks o una integración vía Moodle REST API.

Cuando la herramienta vive dentro del mismo Moodle

Si estás construyendo un plugin nativo de Moodle, LTI añade complejidad innecesaria. Los plugins tienen acceso directo al core, al gradebook y a los eventos. En ese caso, puede ser mejor diseñar un plugin siguiendo buenas prácticas de desarrollo de plugins Moodle.

Cuando el cliente no controla el LMS

Algunas plataformas SaaS restringen qué herramientas LTI se pueden registrar o cobran por habilitar integraciones externas. Antes de diseñar la arquitectura, verifica que el cliente tiene permisos administrativos para registrar herramientas LTI.

Cuando el overhead no se justifica

Para integraciones simples, con un único tenant y sin retorno de notas, una integración SSO basada en SAML u OIDC independiente puede ser más sencilla de mantener que LTI 1.3 completo.

Cómo probar una integración LTI Moodle antes de producción

Una integración LTI no debería validarse únicamente con “he hecho clic y entra”. El lanzamiento es solo una parte del flujo. También hay que probar roles, cursos, caducidad de tokens, retorno de notas, navegadores, errores esperados y comportamiento ante cambios de configuración.

En proyectos institucionales, este plan de pruebas debería convertirse en un checklist repetible por release. Así se evitan regresiones cuando cambias librerías JWT, rotas claves, añades un nuevo tenant o actualizas Moodle a una nueva versión.

También conviene probar la herramienta embebida y en ventana nueva, en Chrome, Firefox, Safari y dispositivos móviles. Si la institución trabaja con aulas equipadas, tablets o políticas corporativas restrictivas, esas condiciones deben formar parte del plan de pruebas.

Observabilidad y soporte en una integración LTI Moodle

La diferencia entre una demo funcional y una integración mantenible está en la observabilidad. Cuando algo falla en LTI, el problema puede estar en Moodle, en la herramienta externa, en el navegador, en el reloj del servidor, en la caché del JWKS o en la configuración del deployment.

La clave no es solo registrar mucho, sino registrar bien. Lo ideal es poder correlacionar un launch concreto con su tenant, su deployment_id, el navegador, el servicio implicado y la respuesta del LMS, sin exponer datos sensibles del usuario.

• Registra iss, client_id, deployment_id, context_id, user_sub y tipo de mensaje LTI.
• No guardes el JWT completo en logs; registra solo claims mínimos y datos no sensibles.
• Añade métricas de launches correctos, launches fallidos, errores de firma y fallos AGS.
• Monitoriza la disponibilidad del JWKS de Moodle y del token endpoint.
• Genera alertas si aumentan los errores state_mismatch, invalid_signature o jwks_unavailable.
• Documenta un runbook de soporte para administradores Moodle y equipo técnico de la herramienta.

Un buen panel operativo de integración LTI debería permitir responder rápido a tres preguntas: qué Moodle está fallando, qué deployment está afectado y si el problema ocurre en login, launch, Deep Linking, AGS o NRPS.

Checklist técnico para una integración LTI Moodle

Antes de aprobar o auditar una integración LTI con Moodle, verifica estos puntos. Además, si ya tienes una herramienta conectada, este checklist te sirve como base para una auditoría Moodle centrada en integraciones externas.

Conclusión: una integración LTI Moodle debe ser invisible para el alumno

Una integración LTI bien implementada es invisible para el alumno y para el profesor. Funciona, las notas aparecen, nadie llama al soporte técnico y la herramienta externa parece formar parte natural del campus.

Pero llegar ahí requiere entender el protocolo: flujo OIDC, JWT, JWK Sets, AGS, NRPS, Deep Linking, multi-tenancy y privacidad. No es complejo si tienes el mapa claro desde el principio. En cambio, si lo construyes como una integración artesanal, el coste de mantenimiento aparece después.

Por eso, si estás valorando conectar una herramienta externa con Moodle, conviene pensar en arquitectura antes de escribir código. Una integración LTI Moodle sólida no solo resuelve el acceso; también protege datos, simplifica soporte y abre la puerta a un ecosistema EdTech más modular.

El riesgo no está en conseguir que el primer lanzamiento funcione una vez. El riesgo real aparece después: cuando hay que mantener la integración, rotar claves, diagnosticar errores, dar soporte a varios Moodle, garantizar privacidad y asegurar que las notas llegan correctamente al gradebook. Ahí es donde LTI deja de ser una configuración y se convierte en arquitectura.