LTI: запуск инструментов внутри любой LMS

Кратко

Learning Tools Interoperability, почти всегда просто LTI, – стандарт, который позволяет безопасно запускать внешний инструмент (видеоурок, интерактивный плеер, приложение для прокторинга) внутри системы управления обучением (LMS), не копируя контент инструмента в эту LMS. SCORM и cmi5 упаковывают контент и переносят его в LMS, а LTI запускает работающий инструмент, который остаётся на ваших серверах. Поэтому одно развёртывание обслуживает сразу все подключённые LMS. Текущая версия, LTI 1.3, построена на тех же проверенных механизмах веб-безопасности, что и вход в онлайн-банк: OpenID Connect, OAuth 2.0 и токен с цифровой подписью (JWT). Они подтверждают, кто учащийся и из какого курса он пришёл, поэтому единый вход (SSO) в LTI – побочный эффект, а не передача пароля. Если добавить три сервиса LTI Advantage – Deep Linking, Names and Role Provisioning и Assignment and Grade Services, – инструмент сможет предлагать преподавателям выбор контента, читать список группы и записывать оценки прямо в журнал LMS.

Почему это важно

Если вы строите обучающий продукт – видеоплатформу, инструмент интерактивного видео, систему оценивания, – покупатели очень скоро спросят: «А он работает внутри нашей LMS?» В российском вузе это чаще всего Moodle или собственная электронная информационно-образовательная среда (ЭИОС), в компании – корпоративная LMS. LTI позволяет ответить «да» для каждой системы с поддержкой стандарта – через одну интеграцию вместо десятка индивидуальных. Статья написана для L&D-директора, основателя EdTech-компании или продакт-менеджера, которому нужно решить, стоит ли делать поддержку LTI, и объяснить задачу инженерам, не утонув в жаргоне OAuth. Всё сказанное опирается на спецификации, но разбирается простым языком.

Что такое LTI: одна идея

Представьте университетскую LMS как здание с охраной на входе. Внутри – десятки курсов. Преподаватель хочет добавить ваш видеоинструмент в курс «Общая биология». Но инструмент работает в вашем собственном дата-центре, это не файл, который можно передать. Как сделать так, чтобы студент нажал ссылку в «Общей биологии» и сразу оказался в вашем инструменте уже авторизованным, а инструмент знал, кто это и из какого курса он пришёл?

Именно этот обмен и стандартизирует Learning Tools Interoperability – LTI. LTI работает как пропуск для посетителя: он позволяет вашему инструменту войти в любую совместимую LMS и получить её доверие. LMS ручается за учащегося, инструмент проверяет это поручительство, и учащийся переходит из одной системы в другую без второго пароля. Стандарт создал консорциум IMS Global Learning Consortium – теперь он называется 1EdTech, – и это самый распространённый стандарт интеграции в образовательных технологиях.

Одно различие стоит держать в голове на протяжении всей статьи: его чаще всего понимают неверно. Стандарты упаковки, о которых вы могли читать, – SCORM и cmi5 – берут ваш контент, упаковывают его в zip и переносят в LMS, чтобы он работал там. LTI делает наоборот: оставляет инструмент там, где он есть, и открывает его из LMS. SCORM доставляет контент, LTI – доверенную дверь к нему.

Нажмите, чтобы увеличить

Две роли: Platform и Tool

LTI описывает взаимодействие ровно двух сторон, и у каждой в спецификации есть точное название, которое стоит запомнить.

Platform – система, в которой находится учащийся и которая инициирует запуск. Почти всегда это LMS: Moodle вуза, собственная ЭИОС или корпоративная обучающая система. Platform знает, кто учащийся, в каком он курсе и какая у него роль (студент, преподаватель, ассистент).

Tool – внешнее приложение, которое запускают: ваш видеоплеер, интерактивный урок, система тестирования, сервис прокторинга. Tool работает на своей инфраструктуре и полагается на Platform в том, кто к нему пришёл.

Если не путать эти роли, остальное в LTI понятно: Platform ручается, Tool доверяет, а стандарт задаёт подписанные сообщения между ними. Во всей статье «Platform» означает LMS, а «Tool» – то, что вы строите или покупаете.

Как работает запуск LTI 1.3: обмен подписанными сообщениями

Именно эта часть принесла LTI репутацию безопасного решения, и она проще, чем кажется по аббревиатурам, если разобрать её по шагам. Речь пойдёт о современной версии – LTI 1.3, финальный релиз которой IMS выпустил 16 апреля 2019 года. Старый LTI (1.1) использовал более слабый метод подписи, а в 1.3 безопасность построена на тех же проверенных протоколах, что защищают вход по всему вебу: OpenID Connect (OIDC), OAuth 2.0 и JSON Web Tokens (JWT). Каждый объясним по ходу дела, знать их заранее не нужно.

Запуск по шагам.

Шаг 1 – учащийся нажимает ссылку. В курсе «Общая биология» студент открывает ваш видеоурок. Platform не просто переходит по URL, а начинает third-party-initiated login – вход, который инициирует LMS, а не сам учащийся. Platform отправляет первое сообщение на login-URL вашего Tool и сообщает, кто обращается: издателя (iss – идентификатор Platform), login_hint (непрозрачная ссылка на учащегося) и адрес, на который в итоге придёт запуск.

Шаг 2 – Tool отвечает запросом. Tool не доверяет первому сообщению вслепую. Он обращается к authorization endpoint платформы с запросом OpenID Connect – это тот же механизм «Войти через…», которым пользуются потребительские сервисы по всему вебу. OIDC – тонкий слой идентификации поверх OAuth 2.0, стандарта, который позволяет одной системе выдать другой ограниченный доступ в заданных рамках (scope). Простыми словами, Tool говорит: «Platform, если запрос настоящий, пришли подписанное подтверждение того, кто этот учащийся».

Шаг 3 – Platform отправляет подписанный токен. Platform проверяет запрос и возвращает JSON Web Token (JWT) – компактный набор утверждений (claims) с цифровой подписью, которую нельзя незаметно подделать. Подписывает JWT платформа своим приватным ключом. Внутри – claims, без которых запуск бесполезен: тип сообщения (для запуска контента это LtiResourceLinkRequest), версия LTI, deployment ID, личность учащегося и его roles, context (курс «Общая биология») и то, по какой именно ссылке на ресурс перешли.

Шаг 4 – Tool проверяет и открывает. Tool загружает публичные ключи платформы (они опубликованы по стандартному адресу – JWKS) и проверяет ими подпись. Если подпись верна, claims подлинные и не изменены; если кто-то подменил хоть один символ, проверка не пройдёт. Tool также проверяет одноразовый nonce, чтобы сообщение нельзя было отправить повторно. Только после этого Tool показывает видеоурок – нужному учащемуся, в нужном курсе, с нужной ролью.

Посмотрите, что получилось: учащийся уже в вашем инструменте, аутентифицирован и с контекстом курса, а пароль в вашу систему не вводил ни разу. Поэтому единый вход (SSO) – следствие LTI, а не его механизм. Механизм – подписанный проверяемый токен, а удобный вход – бонус. Формулировка важна: если описать LTI инженеру как «он логинит пользователя», разработка пойдёт не в ту сторону.

Отсюда и граница ответственности. LTI передаёт в Tool личность, которую уже установила LMS, но сам её не устанавливает. Если вуз пускает студентов в Moodle по своей учётной записи, Tool получит ровно такую же степень уверенности. Для промежуточной и итоговой аттестации Правила применения электронного обучения и ДОТ (ПП № 1678 в редакции ПП № 517 от 06.05.2026) позволяют вузам, колледжам и организациям ДПО идентифицировать учащегося через ЕСИА («Госуслуги») и ЕБС – самостоятельно или через сервис прокторинга. Это отдельный слой поверх LTI, а не его функция; подробнее – в статье о подтверждении личности на экзаменах.

Нажмите, чтобы увеличить

Почему LTI 1.3 заменил LTI 1.1: вопрос безопасности

LTI 1.1 ещё встречается на практике, поэтому стоит понимать, почему стандарт пошёл дальше. LTI 1.1 подписывал сообщения через OAuth 1.0: обеим сторонам нужен был общий секретный ключ, а на каждый запрос приходилось вычислять сложную криптографическую подпись. Это работало, но общий секрет – слабое место: он утекает, его трудно регулярно менять, а у самой схемы подписи были известные недостатки. По формулировке 1EdTech, старые механизмы безопасности «продемонстрировали уязвимости», и ИТ-директора учебных заведений обоснованно беспокоились за персональные данные студентов, которые передавались между системами на такой основе.

LTI 1.3 заменил всё это современным 1EdTech Security Framework: OAuth 2.0 поверх HTTPS, OpenID Connect и JWT, подписанные с помощью пары из публичного и приватного ключей. Выгоды вполне конкретные. Общего секрета, который мог бы утечь, больше нет: Platform подписывает приватным ключом, а Tool проверяет парным публичным. Модель не зависит от браузера, поэтому LTI Tool может быть нативным мобильным или десктопным приложением, а не только веб-страницей. А поскольку слой безопасности отделён от ядра спецификации, обе части могут развиваться независимо.

У этого есть цена: работа с парой ключей – новая операционная задача для разработчиков Tool, а корректная ротация ключей и публикация JWKS требуют усилий. Но это понятная работа на библиотеках, которыми веб-команды и так пользуются. Разовые затраты на освоение окупаются более надёжной моделью безопасности без общего секрета. Для инструмента, который будет хранить данные студентов, выбор очевиден.

LTI Advantage: три сервиса для реальной работы

Ядро LTI 1.3 приводит учащегося в Tool с проверенным контекстом. Это полезно, но преподавателю обычно нужно больше, чем дверь. Он хочет выбрать, какое видео попадёт в урок, увидеть, кто в группе, и чтобы оценки за тест автоматически возвращались в журнал LMS. Именно эти три задачи решает LTI Advantage. Это не отдельный стандарт, а набор из трёх необязательных сервисов поверх ядра LTI 1.3; все они используют ту же защиту на JWT и OAuth.

Deep Linking позволяет преподавателю при сборке курса просматривать контент в вашем Tool, выбирать нужное и передавать выбор в LMS в виде готовых ссылок. Без него у преподавателя есть только общий вход в инструмент, а до нужного видео приходится добираться вручную. С ним он нажимает «Добавить контент», выбирает «Клеточное дыхание, часть 2» прямо в вашем инструменте, и LMS сохраняет прямую ссылку именно на этот урок. Deep Linking превращает инструмент из одной общей двери в каталог контента.

Names and Role Provisioning Services (NRPS) позволяет Tool безопасно получать у Platform список участников курса: кто записан и какая у каждого роль. Благодаря этому видеоинструмент может показать преподавателю список группы, заранее завести запись для каждого студента или понять, что урок открыл ассистент, а не учащийся. Tool запрашивает список, Platform возвращает его через защищённый API с доступом, ограниченным средствами OAuth.

Assignment and Grade Services (AGS) позволяет Tool записывать оценки, баллы, прогресс и комментарии в журнал LMS. Учащийся проходит интерактивное видеотестирование, набирает 86%, и AGS отправляет этот балл в журнал «Общей биологии» без ручного ввода. AGS состоит из трёх частей: line item (колонка в журнале), score (что набрал учащийся) и results (итог, который можно прочитать). Для любого продукта, который выставляет оценки, AGS – это разница между «преподаватель вбивает каждый балл вручную» и «баллы появляются сами».

Важная оговорка: каждый сервис необязателен и согласуется отдельно для каждого развёртывания. Если ваш Tool поддерживает AGS, это ещё не значит, что конкретная платформа его предоставит. Доступность зависит от того, что реализовано и в Platform, и в Tool, и что включило учебное заведение. Закладывайте плавную деградацию: запуск должен работать, даже когда отправка оценок недоступна.

Нажмите, чтобы увеличить

Пример: один инструмент, четыре LMS, арифметика интеграции

На цифрах выгода LTI нагляднее. Допустим, вы продаёте инструмент интерактивного видеотестирования, а четыре клиента используют четыре разные системы: Moodle одного вуза, собственную ЭИОС другого, корпоративную LMS производственного холдинга и платформу онлайн-школы. Каждый хочет видеть ваш инструмент в своих курсах, а оценки – в своём журнале.

Без стандарта пришлось бы делать отдельную интеграцию под каждую систему: аутентификацию, сопоставление учётных записей, синхронизацию списков и возврат оценок – четыре раза. Возьмём по осторожной оценке четыре инженеро-недели на каждую интеграцию плюс постоянную поддержку, ведь каждая LMS меняет свой API:

Отдельные интеграции  = 4 системы × 4 инж-недели  = 16 инж-недель на разработку
                      + 4 отдельных направления поддержки, навсегда

С LTI 1.3 и AGS стандарт реализуется один раз – один сценарий запуска, одна проверка JWT, один клиент AGS для возврата оценок, – после чего проверяется соответствие. Дальше любая LTI-совместимая LMS работает через этот единый код:

Интеграция LTI        = 1 реализация (запуск + AGS)   ≈ 4–6 инж-недель
                      + 1 направление поддержки стандарта
Подключение новой LMS = настройка, а не код           ≈ часы, не недели

Экономия не только в первых неделях: пятая, шестая и десятая LMS почти ничего не стоят, потому что подключение новой совместимой платформы – задача настройки, а не инженерный проект. Поправка для российского рынка: в Moodle поддержка LTI 1.3 встроена, а у собственных ЭИОС вузов и корпоративных LMS её нужно проверять у каждого заказчика до продажи. Где LTI нет, остаётся отдельная интеграция, но только для этой системы, а не для каждой. Принцип «сделать один раз, запускать везде» – главная коммерческая причина существования LTI.

LTI или стандарты упаковки: что когда использовать

LTI часто обсуждают вместе со SCORM, xAPI и cmi5, и команды начинают думать, что выбрать нужно что-то одно. На деле стандарты решают разные задачи и нередко используются вместе. Проще всего выбирать, ответив на один вопрос: контент должен жить внутри LMS или оставаться работающим сервисом под вашим контролем?

Если нужен самодостаточный курс, который любая LMS может хранить и запускать сама – даже офлайн и даже если вашей компании однажды не станет, – его упаковывают в SCORM или cmi5. Если нужен работающий инструмент, который вы размещаете у себя, постоянно обновляете и открываете из многих LMS, его запускают через LTI. Видеоплатформа, которая каждую неделю получает новые функции, подстраивается под учащегося или выполняет тяжёлую серверную обработку, – это Tool для запуска. Неизменный модуль по охране труда, который должен работать в изолированной LMS клиента, – контент для упаковки.

В таблице – сравнение, которое обычно и нужно командам.

Итак: упаковывайте в SCORM или cmi5, когда контент должен быть самодостаточным артефактом, которым владеет LMS; запускайте через LTI, когда вы – сервис, к которому подключаются многие учебные заведения, и код остаётся под вашим контролем. Многие реальные продукты делают и то и другое: предлагают SCORM-пакет как запасной вариант и более функциональный запуск через LTI. А инструмент для обучающего видео часто сочетает LTI для интерактивной работы с xAPI Video Profile для посекундного трекинга. Полное сравнение четырёх вариантов – в статье SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать.

Нажмите, чтобы увеличить

Частые ошибки, на которые уходит время

Несколько ошибок с LTI повторяются из проекта в проект. Каждую дёшево предотвратить заранее и дорого обнаружить уже в LMS клиента.

Первая – строить на LTI 1.1 в 2026 году. Подпись OAuth 1.0 в LTI 1.1 – именно та модель безопасности, на смену которой и создан 1.3. Новые разработки должны ориентироваться на LTI 1.3 и LTI Advantage; 1.1 – устаревшая версия, которую стоит поддерживать, только если этого требует конкретный заказчик со старой установкой.

Вторая – описывать LTI как вход по паролю. Это не так. Platform подтверждает личность подписанным токеном, который Tool проверяет криптографически; SSO – результат. Команды, которые проектируют это как передачу учётных данных, делают не то и теряют гарантии безопасности, которые даёт JWT.

Третья – считать, что сервисы LTI Advantage доступны всегда. Ядро запуска и три сервиса (Deep Linking, NRPS, AGS) согласуются для каждого развёртывания. Платформа может разрешить запуск, но не возврат оценок. Закладывайте плавную деградацию: отсутствие scope AGS не должно ломать урок.

Четвёртая – экономить на проверке JWT. «На тесте работало» часто означает, что подпись, nonce, aud и срок действия проверялись небрежно. LTI Tool, который не проверяет токен полностью по опубликованным ключам Platform, – дыра в безопасности. Проверяйте каждый claim при каждом запуске.

Пятая – относиться к данным списков и оценок как к малозначимым. NRPS даёт реальные ФИО и роли студентов, а AGS работает с их оценками – это персональные данные по 152-ФЗ. Учебное заведение здесь оператор, а ваш Tool обычно обрабатывает данные по его поручению (ч. 3 ст. 6), поэтому в договоре нужно поручение с перечнем данных, действий и целей. С 1 июля 2025 года обрабатывать ПДн граждан РФ в базах за рубежом нельзя (ч. 5 ст. 18), так что Tool и его база данных должны размещаться в России. Решите, что храните, зачем и на какой срок, до первого вызова NRPS. Это инженерные рекомендации, а не юридическая консультация.

Построить или купить: где LTI в этом решении

Как всегда, начнём с бизнес-вопроса. Поддержку LTI редко покупают целиком: это разработка, но ограниченная, и её объём зависит от того, на чьей вы стороне.

Если вы строите Tool (типичный случай для видеопродукта или системы оценивания), реализация LTI 1.3 с нужными сервисами Advantage – реальная, но чётко очерченная инженерная задача: запуск через OIDC, проверка и подпись JWT, управление ключами и JWKS, клиент AGS для возврата оценок. Open-source-библиотеки LTI есть для большинства языков и снимают большую часть рутины, поэтому основные усилия уходят на безопасность и подтверждение соответствия. 1EdTech ведёт формальную сертификацию LTI 1.3, но российского заказчика обычно больше убеждает работающий пилот в его собственном Moodle или ЭИОС. Если вы продаёте Tool вузам и колледжам, учтите и п. 21 ПП № 1678: ПО в составе ДОТ должно создаваться и использоваться по законодательству РФ и (или) входить в реестр российского ПО – для государственных заказчиков на практике это означает реестр.

Если вы строите Platform (то есть сами делаете LMS), объём работ по LTI больше: нужно выпускать подписанные токены, держать endpoints OIDC и JWKS, предоставлять API NRPS и AGS. Это осознанная инвестиция в платформу, и оправдана она, только если совместимость со сторонними инструментами – ключевое обещание продукта. В более общем виде этот выбор разобран в статье Построить, купить или расширить существующую LMS. Чтобы с первого раза правильно оценить и выстроить интеграцию, скачайте чек-лист готовности к интеграции LTI 1.3.

Где здесь Фора Софт

Фора Софт разрабатывает ПО для видеообучения, стриминга, видеоконференций и интерактивных плееров с 2005 года, на счету 250+ выпущенных проектов. В обучающих продуктах мы регулярно помогаем принять решение, которому посвящена статья: упаковать курс в SCORM или cmi5, если он должен жить внутри LMS клиента, или сделать видеоинструмент доступным через запуск LTI 1.3, если это работающий сервис, к которому подключаются многие учебные заведения. Обычно мы работаем на уровне видео и интерактива: делаем инструмент интерактивного видео, который корректно запускается в Moodle, ЭИОС вуза или корпоративной LMS, читает список группы через NRPS и возвращает баллы через AGS. Так оценка учащегося и аналитика вовлечённости берутся из одного проверенного запуска. Запуск и возврат оценок мы рассчитываем на реальную LMS учебного заведения под нагрузкой, а не на тест в песочнице.

Главное

• LTI запускает ваш работающий инструмент из любой совместимой LMS; контент он не упаковывает.
• Platform (LMS) ручается; Tool (ваше приложение) доверяет подписанному токену.
• LTI 1.3 использует OpenID Connect, OAuth 2.0 и подписанный JWT; SSO – результат, а не способ установить личность.
• LTI Advantage добавляет Deep Linking, доступ к списку участников (NRPS) и возврат оценок (AGS).
• Реализуйте LTI один раз, и все совместимые LMS будут работать через один код; поддержку в ЭИОС проверяйте заранее.
• Проверяйте каждый claim JWT; данные списков и оценок – персональные данные по 152-ФЗ, хранить их нужно в РФ.

Что почитать дальше

• SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать
• Интеграция с Moodle
• Интеграция с российскими LMS и ЭИОС вузов