Migrar de LTI 1.1 a LTI 1.3: guía práctica para equipos de herramientas

Si has construido una herramienta de e-learning que se conecta a un LMS, hay una fecha límite que se acerca en silencio. LTI 1.1, junto con 1.0 y 1.2, ha sido oficialmente retirado por 1EdTech, el organismo que mantiene el estándar. Las plataformas principales han dejado clara su posición: LTI 1.3 se está convirtiendo en el requisito mínimo para cualquier herramienta que intercambie datos personales o sensibles de estudiantes. Si tu integración sigue en 1.1, ya es una migración con reloj, no un «algún día».

La buena noticia es que el camino se conoce y está documentado. La mala es que 1.3 no es un salto de versión menor. Es un modelo de seguridad distinto. Tratarlo como una actualización pequeña es cómo los equipos acaban con lanzamientos rotos y calificaciones ausentes en producción. Esta guía cubre los cambios, el orden de la migración y los problemas que realmente aparecen.

Qué cambió realmente entre 1.1 y 1.3

Durante la mayor parte de la historia de LTI, las versiones nuevas solo añadían capacidades. La 1.3 rompe ese patrón: cambian el formato de mensaje y todo el modelo de seguridad, por eso este salto exige una migración real.

LTI 1.1 autenticaba mensajes con firmas de estilo OAuth 1.0a: ambos lados conocían un consumer key y un secret compartidos y firmaban solicitudes con HMAC-SHA1. Funcionaba, pero un secreto compartido trae riesgos reales de repetición y sustitución cuando se filtra.

LTI 1.3 elimina ese modelo y adopta una pila moderna: OpenID Connect para el inicio de sesión, JSON Web Tokens (JWT) firmados con claves asimétricas para la integridad del mensaje y tokens portadores OAuth 2.0 para llamadas de servicio. En lugar de compartir un secreto, la plataforma firma con una clave privada y publica la clave pública correspondiente en una URL. Tu herramienta obtiene esa clave para comprobar que el lanzamiento vino de la plataforma.

Eso afecta a todo. En 1.1, un lanzamiento era un conjunto plano de parámetros POST más una firma. En 1.3 es un JWT firmado con datos organizados en claims. La configuración ya no es una URL de lanzamiento, una clave y un secreto: durante el registro intercambias URLs e identificadores y la plataforma asigna client_id y deployment_id. La devolución de notas, la lista de curso y el deep linking pasan a ser servicios LTI Advantage disponibles solo en 1.3. Antes de cada llamada, tu herramienta obtiene un token OAuth 2.0 mediante una aserción JWT firmada. El alcance real es OIDC, validación JWT, gestión de claves y manejo de OAuth 2.0.

La migración, paso a paso

El orden importa. Cada paso supone que el anterior está terminado y verificado.

Paso 1: confirma 1.3 y decide el alojamiento

Primero confirma que los LMS que usan tus clientes soportan LTI 1.3: Canvas, Moodle, Brightspace y Blackboard ya lo hacen. Después decide si la herramienta 1.3 vivirá en el mismo dominio que la 1.1 o en otro. Algunas plataformas actualizan automáticamente los enlaces de curso existentes cuando despliegas 1.3 en el mismo nombre de dominio completo. Si cambias de dominio, quizá necesites migrar enlaces para que sigan funcionando columnas de calificaciones y enlaces existentes. Decide pronto; cambiarlo después obliga a rehacer configuración.

Paso 2: implementa el inicio de sesión OIDC

Los lanzamientos LTI 1.3 comienzan con un login OpenID Connect iniciado por terceros para proteger contra falsificación de solicitudes entre sitios. La plataforma llama primero al endpoint de login OIDC de tu herramienta. Esta redirige al endpoint de autorización de la plataforma con un valor state, normalmente guardado en una cookie, y un nonce.

Expón este endpoint. El state que generas se comprueba en el siguiente paso para confirmar que el lanzamiento que vuelve es el que iniciaste.

Paso 3: recibe el lanzamiento y valida el JWT

La plataforma genera el id_token, el JWT con los datos de lanzamiento, y publica un formulario POST hacia tu URI de redirección. Cuando llega, haz tres cosas por orden.

Primero, comprueba que el state devuelto coincide con el que guardaste. Si no coincide, rechaza el lanzamiento. Segundo, descompón y valida la firma JWT. Un JWT tiene tres secciones Base64 separadas por puntos: cabecera con identificador de clave y algoritmo, carga con claims y firma. Obtén la clave pública de la plataforma, usando el identificador de la cabecera, desde su URL de conjunto de claves y verifica la firma. Tercero, valida emisor, audiencia (client_id), nonce y vencimiento. Solo entonces confía en el lanzamiento y lee los datos de usuario, curso y recurso.

Paso 4: vuelve a implementar servicios como LTI Advantage

Si tu herramienta devuelve notas, lee el listado del curso o admite selección de contenido, ahora son servicios LTI Advantage y funcionan de otra manera. Antes de llamarlos, pide un token de acceso OAuth 2.0 al endpoint de tokens de la plataforma enviando una aserción de cliente JWT firmada. Recibes un token portador y lo usas para el servicio.

Los tres servicios frecuentes son Assignment and Grade Services (AGS) para publicar notas, Names and Role Provisioning Services (NRPS) para recuperar la lista y Deep Linking para que el profesor elija contenido de tu herramienta. Todos necesitan antes el paso de token; suele ser donde se concentra el código nuevo.

Paso 5: registra tu herramienta en la plataforma

El registro sustituye el intercambio antiguo de clave y secreto. Entregas el dominio, URI de login OIDC, URI de redirección y URL de tu conjunto de claves públicas. La plataforma devuelve client_id, deployment_id, endpoints de autenticación y token, y su URL de claves públicas.

Guarda todo. Un lanzamiento 1.3 queda identificado de forma única por emisor, client_id y deployment_id. Necesitas los tres para relacionar un lanzamiento entrante con la configuración correcta, especialmente si una herramienta atiende varias plataformas o despliegues.

Paso 6: prueba primero en preproducción

Nunca hagas esto primero en producción. Levanta la integración 1.3 en el entorno de prueba o beta de la plataforma, realiza lanzamientos reales, publica calificaciones reales y confirma que llegan bien. La recomendación de todas las plataformas es validar por completo 1.3 en staging antes de tocar producción.

Paso 7: cambia y después retira 1.1

Cuando la preproducción esté validada, despliega en producción. Según la decisión de alojamiento del paso 1, los enlaces existentes se actualizarán solos o necesitarán migración. Cuando 1.3 esté confirmado en producción, elimina 1.1. Mantener ambas versiones de la misma herramienta en paralelo no se recomienda y algunas plataformas ni lo permiten en el mismo dominio.

Los riesgos que de verdad causan problemas

Las calificaciones pueden desaparecer temporalmente del libro. Es alarmante para el profesorado, pero a menudo es comportamiento esperado. En algunas integraciones, las notas existentes vuelven a aparecer tras relanzar la herramienta y volver a emparejar cuentas. No se han perdido, pero sin aviso recibirás tickets de soporte urgentes. Comunícalo antes de migrar.

Enlaces de tareas duplicados o rotos. Las migraciones suelen dejar enlaces 1.1 que ya no apuntan a nada. Puede haber dos tareas: una versión 1.3 que funciona y otra 1.1 muerta. Incluye identificar y limpiar enlaces antiguos, e indica a los docentes cuál conservar.

Los ID de usuario pueden cambiar. Aunque la especificación busca compatibilidad de contenido, algunos identificadores cambian. El ID que recibe tu herramienta en 1.3 puede ser distinto del almacenado en 1.1. Si vinculas registros al ID de usuario LTI, planifica un paso de reemparejado de identidades al primer lanzamiento 1.3 o dejarás el historial huérfano.

Huecos en cómo aparecen notas y comentarios. Algunas integraciones 1.3 no se comportan igual que 1.1 dentro del LMS: pueden dejar de verse entregas en la interfaz nativa o iconos de nota aunque los datos estén bien. Prueba todo el flujo de calificación del profesor, no solo que un lanzamiento tenga éxito.

La gestión de claves es una responsabilidad continua. En 1.1 guardabas un secreto. En 1.3 posees un par privado-público, publicas un conjunto de claves y debes rotarlas y mantener disponible el endpoint. Si la URL de claves cae, todos los lanzamientos fallan al validar la firma. Esta superficie operativa nueva exige monitorización.

La revisión de seguridad puede ser la parte más lenta. Muchas instituciones envían una integración 1.3 nueva a ciberseguridad o TI y quizá deban incluir tus URLs en una lista permitida. La evaluación suele consumir más tiempo que el código y está fuera de tu control. Empieza pronto la conversación con clientes institucionales para que no bloquee el lanzamiento.

En resumen

LTI 1.3 exige más trabajo que actualizaciones anteriores porque sustituye el fundamento de seguridad, no solo añade funciones. Login OIDC, validación JWT, tokens OAuth 2.0 y gestión de claves son implementación real, no configuración. La retirada de 1.1 es real y las plataformas la aplican: la cuestión es cuándo, no si.

Sigue el orden correcto, prueba el flujo completo en preproducción y comunica de más los cambios de enlaces y libro de calificaciones al profesorado afectado. Los equipos que se queman tratan 1.3 como un cambio de versión y descubren en producción que el modelo de seguridad cambió bajo sus pies.

Construyo y mantengo plataformas de e-learning e integraciones LMS a medida para equipos edtech y L&D, incluidas implementaciones LTI 1.3 y LTI Advantage. Si estás planeando una migración o una integración desde cero, ese es exactamente el tipo de trabajo en el que ayudo.