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.

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.

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.

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.

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

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 una debe tener su propio Client ID y, preferiblemente, su propia configuración criptográfica. Compartir claves entre tenants complica la rotación y reduce el aislamiento.

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.

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 es opaco y específico del contexto. 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.

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.

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.