Chapitre 9.2 — LTI 1.1, l’héritage

⏱️ TL;DR — LTI 1.1 (2012) a démocratisé le branchement d’outils. Son lancement est un formulaire HTML auto-soumis (POST) de la plateforme vers l’URL de l’outil, dont les champs sont signés en OAuth 1.0 avec un secret partagé (une paire clé + secret par intégration). L’outil recalcule la signature HMAC-SHA1 pour vérifier l’authenticité. Simple, mais daté : secret symétrique à distribuer et protéger, cryptographie ancienne, difficile à sécuriser à grande échelle. 1EdTech a donc déprécié LTI 1.1 au profit de 1.3. On l’étudie pour comprendre l’existant (tu en croiseras) — pas pour en construire du neuf.

🎯 Objectifs

• Comprendre la mécanique d’un lancement LTI 1.1 (POST signé OAuth 1.0).
• Lire les paramètres d’un lancement 1.1 et le rôle de la signature.
• Nommer les faiblesses qui ont conduit à l’abandonner.
• Savoir reconnaître du 1.1 dans un système existant et planifier la migration vers 1.3.

Le lancement 1.1 : un POST signé

En LTI 1.1, lancer un outil, c’est poster un formulaire. Quand l’élève clique sur l’activité, la plateforme génère une page avec un <form> (souvent auto-soumis en JavaScript) qui POST vers l’URL de lancement de l’outil, avec une série de champs. Schématiquement :

<form action="https://outil.example/launch" method="POST">
  <input name="lti_message_type" value="basic-lti-launch-request">
  <input name="lti_version" value="LTI-1p0">
  <input name="resource_link_id" value="res-4815">
  <input name="user_id" value="u-2342">
  <input name="roles" value="Learner">
  <input name="context_id" value="course-9271">
  <input name="lis_person_name_full" value="Camille Martin">
  <input name="oauth_consumer_key" value="formacampus-key">
  <input name="oauth_signature_method" value="HMAC-SHA1">
  <input name="oauth_timestamp" value="1700000000">
  <input name="oauth_nonce" value="a1b2c3d4">
  <input name="oauth_version" value="1.0">
  <input name="oauth_signature" value="q3F...signature...=">
  <!-- ... -->
</form>

Les champs se lisent en trois groupes :

• Le message LTI : lti_message_type=basic-lti-launch-request, lti_version=LTI-1p0.
• Le contexte pédagogique : resource_link_id (l’activité précise), user_id, roles (Learner, Instructor…), context_id (le cours), des infos de personne (lis_person_name_full, etc.).
• La signature OAuth 1.0 : oauth_consumer_key (identifie l’intégration), oauth_signature_method=HMAC-SHA1, oauth_timestamp, oauth_nonce, et surtout oauth_signature.

La sécurité : un secret partagé

Avant l’intégration, plateforme et outil se sont mis d’accord sur une paire consumer_key + shared_secret. La plateforme signe l’ensemble des paramètres du POST avec ce secret (HMAC-SHA1, selon OAuth 1.0) et joint le résultat dans oauth_signature. À la réception, l’outil recalcule la même signature à partir des paramètres reçus et de son exemplaire du secret : si les deux signatures coïncident, le lancement est authentique et non altéré.

💡 Réflexe — La signature protège l’intégrité et l’authenticité du lancement : sans elle, n’importe qui pourrait POSTer de faux paramètres (« je suis enseignant », « voici l’utilisateur X ») à ton outil. Ne jamais faire confiance à un lancement dont la signature n’est pas vérifiée — c’est vrai en 1.1 (OAuth 1.0) comme en 1.3 (JWT). Un lancement non vérifié est une usurpation en puissance.

Pourquoi on l’abandonne

LTI 1.1 a rendu d’immenses services, mais son modèle de sécurité a vieilli :

La réponse de 1EdTech : LTI 1.3, fondé sur OpenID Connect et des JWT signés par des clés asymétriques (privée d’un côté, publique de l’autre, publiée via JWKS). Plus de secret partagé à distribuer, une cryptographie moderne, et un socle propre pour les services de LTI Advantage. En conséquence, LTI 1.1 est déprécié : les nouveaux développements se font en 1.3.

⚠️ Piège — Démarrer un nouveau projet en LTI 1.1 « parce que les tutos sont plus simples ». C’est une dette immédiate : de plus en plus de plateformes refusent le 1.1, et tu devras tout migrer. Pour du neuf : LTI 1.3 d’emblée. Le 1.1, tu l’apprends pour comprendre et migrer l’existant, pas pour le reproduire.

🔌 Côté intégration — Beaucoup d’établissements ont encore des intégrations 1.1 en production. Savoir les reconnaître (POST signé, oauth_consumer_key, lti_version=LTI-1p0) et proposer une migration vers 1.3 est une prestation à part entière — et un argument de sérieux : tu ne te contentes pas de brancher, tu modernises et sécurises l’existant.

🧭 Sur FormaCampus — FormaCampus avait un premier branchement de son studio en LTI 1.1 avec une école pilote (clé + secret échangés par e-mail — déjà une mauvaise pratique). Au moment d’industrialiser, l’équipe refait tout en 1.3 : plus de secret partagé, une paire de clés propre, et un socle prêt pour renvoyer les notes (AGS). L’école pilote est migrée, l’ancienne intégration 1.1 débranchée.

📚 La spec — LTI 1.0/1.1 relève des specs historiques de 1EdTech (ex-IMS Global). La signature suit OAuth 1.0 (HMAC-SHA1). 1EdTech recommande officiellement la migration vers LTI 1.3 / LTI Advantage ; considère le 1.1 comme legacy. Détails et calendrier de fin de vie : 1edtech.org.

✏️ Exercices

Exercice 1 — Lis le lancement. On te montre un POST contenant lti_version=LTI-1p0, oauth_consumer_key=abc, oauth_signature_method=HMAC-SHA1, roles=Instructor. De quelle version de LTI s’agit-il ? Que vérifie l’outil avant de faire confiance à roles=Instructor ?

Exercice 2 — Le secret fuit. Dans une intégration 1.1, le shared_secret d’un outil se retrouve exposé dans un dépôt Git public. Quel est le risque exact, et pourquoi LTI 1.3 réduit-il ce type de risque ?

🧠 Quiz de révision

Chapitre suivant : LTI 1.3 : OIDC + JWT — le modèle de sécurité moderne, clés asymétriques et JWKS.