Von LTI 1.1 zu LTI 1.3 migrieren: ein Praxisleitfaden für Tool-Teams

Wenn Sie ein E-Learning-Tool gebaut haben, das sich in ein LMS integriert, kommt eine Frist leise näher. LTI 1.1 sowie 1.0 und 1.2 wurden von 1EdTech, der Organisation hinter dem Standard, offiziell abgekündigt. Große Plattformen haben ihre Position klargemacht: LTI 1.3 wird zur Mindestanforderung für Tools, die personenbezogene oder sensible Lerndaten austauschen. Läuft Ihre Integration noch auf 1.1, ist sie kein vielleicht-später-Thema mehr, sondern eine Migration mit Uhr.

Die gute Nachricht: Der Migrationsweg ist bekannt und dokumentiert. Die schlechte: 1.3 ist kein kleines Versionsupdate. Es ist ein anderes Sicherheitsmodell. Wer es wie ein kleines Upgrade behandelt, bekommt fehlerhafte Launches und fehlende Noten in Produktion. Dieser Leitfaden erklärt die wirklichen Änderungen, die Schritte in der richtigen Reihenfolge und die Stellen, an denen Teams stolpern.

Was sich zwischen 1.1 und 1.3 wirklich geändert hat

Lange Zeit fügten neue LTI-Versionen nur Funktionen hinzu. 1.3 durchbricht dieses Muster: Nachrichtenformat und gesamtes Sicherheitsmodell ändern sich. Deshalb braucht dieser Sprung eine echte Migration.

LTI 1.1 authentifizierte Nachrichten mit Signaturen nach OAuth-1.0a-Art: Beide Seiten kannten einen gemeinsamen consumer key und ein secret und signierten Anfragen mit HMAC-SHA1. Das funktionierte, aber gemeinsame Geheimnisse bergen bei Verlust reale Wiederholungs- und Ersetzungsrisiken.

LTI 1.3 ersetzt das durch einen modernen Stack: OpenID Connect für den Login-Handshake, JSON Web Tokens (JWTs) mit asymmetrischen Schlüsseln für Nachrichtenintegrität und OAuth-2.0-Bearer-Tokens für Service-Aufrufe. Statt eines gemeinsamen Secrets signiert die Plattform mit einem privaten Schlüssel und veröffentlicht den passenden öffentlichen Schlüssel an einer URL. Ihr Tool holt diesen Schlüssel und prüft damit, dass ein Launch wirklich von der Plattform stammt.

Das wirkt überall nach. Ein 1.1-Launch war ein flacher Satz von POST-Parametern plus Signatur. Ein 1.3-Launch ist ein signiertes JWT mit strukturierten Claims. Konfiguriert wird nicht mehr nur mit Launch-URL, Schlüssel und Secret: Bei der Registrierung tauschen Sie URLs und Kennungen aus; die Plattform vergibt client_id und deployment_id. Auch Notenrückgabe, Kursliste und Deep Linking laufen als LTI Advantage nur auf 1.3. Vor jedem Service-Aufruf holt Ihr Tool ein OAuth-2.0-Token mit einer signierten JWT-Assertion. Sie ändern also nicht nur eine Konfigurationsdatei. Sie implementieren OIDC, JWT-Prüfung, Schlüsselverwaltung und OAuth-2.0-Tokenhandling.

Die Migration, Schritt für Schritt

Die Reihenfolge ist wichtig. Jeder Schritt setzt voraus, dass der vorige fertig und geprüft ist.

Schritt 1: 1.3-Unterstützung bestätigen und Hosting festlegen

Prüfen Sie zuerst, ob die LMS Ihrer Kunden LTI 1.3 unterstützen; Canvas, Moodle, Brightspace und Blackboard tun es inzwischen. Entscheiden Sie dann: Läuft das 1.3-Tool auf derselben Domain wie 1.1 oder auf einer neuen? Manche Plattformen aktualisieren bestehende Kurslinks automatisch, wenn die 1.3-Version unter demselben vollqualifizierten Domainnamen läuft. Bei einer neuen Domain brauchen Sie womöglich einen Link-Migrationsschritt, damit Links und Notenbuchspalten erhalten bleiben. Klären Sie das früh, denn später bedeutet die Änderung neue Konfiguration.

Schritt 2: OIDC-Login-Initiierung implementieren

LTI-1.3-Launches beginnen mit einem von Dritten initiierten OpenID-Connect-Login, der vor Cross-Site-Request-Forgery schützt. Die Plattform ruft zuerst den OIDC-Login-Endpunkt Ihres Tools auf. Ihr Tool leitet zum Autorisierungsendpunkt der Plattform zurück und übergibt dabei einen state-Wert, den es meist in einem Cookie speichert, sowie einen nonce.

Stellen Sie diesen Endpunkt bereit. Der erzeugte state wird im nächsten Schritt geprüft, damit Sie wissen, dass der zurückkehrende Launch wirklich der von Ihnen gestartete ist.

Schritt 3: Launch empfangen und JWT prüfen

Die Plattform erstellt das id_token, also das JWT mit Launch-Daten, und sendet es per Formular-POST an Ihre Redirect-URI. Bei Ankunft tun Sie drei Dinge in dieser Reihenfolge:

Erstens prüfen Sie, ob state dem gespeicherten Wert entspricht. Wenn nicht, lehnen Sie den Launch ab. Zweitens entpacken und prüfen Sie die JWT-Signatur. Ein JWT besteht aus drei Base64-Abschnitten mit Punkten: Header mit Schlüssel-ID und Algorithmus, Payload mit Claims und Signatur. Holen Sie den öffentlichen Schlüssel der Plattform über die Schlüssel-ID aus ihrer veröffentlichten Keyset-URL und validieren Sie die Signatur. Drittens validieren Sie Claims: Issuer, Audience (client_id), nonce und Ablaufzeit müssen den Erwartungen entsprechen. Erst danach vertrauen Sie dem Launch und lesen Nutzer-, Kurs- und Ressourceninformationen.

Schritt 4: Services als LTI Advantage neu implementieren

Wenn Ihr Tool Noten zurückschreibt, Kurslisten liest oder Inhaltsauswahl unterstützt, sind das nun LTI-Advantage-Services und sie arbeiten anders. Vor jedem Aufruf fordert Ihr Tool vom Token-Endpunkt ein OAuth-2.0-Access-Token an, indem es eine signierte JWT-Client-Assertion sendet. Es erhält ein Bearer-Token und nutzt es für den Service.

Die drei häufigen Services sind Assignment and Grade Services (AGS) für Noten, Names and Role Provisioning Services (NRPS) für Kurslisten und Deep Linking, damit Lehrkräfte spezifische Inhalte Ihres Tools in einen Kurs einbetten können. Vor jedem steht der Token-Schritt; hier entsteht meist der meiste neue Code.

Schritt 5: Tool bei der Plattform registrieren

Die Registrierung ersetzt den alten Austausch von Schlüssel und Secret. Sie geben Domain, OIDC-Login-URI, Redirect-URIs und öffentliche Keyset-URL Ihres Tools an. Die Plattform gibt client_id, deployment_id, Authentifizierungs- und Token-Endpunkte sowie ihre öffentliche Keyset-URL zurück.

Speichern Sie alles. Ein 1.3-Launch wird durch Issuer, client_id und deployment_id eindeutig bestimmt. Sie brauchen alle drei, um einen Launch der richtigen Konfiguration zuzuordnen, besonders wenn ein Tool mehrere Plattformen oder Deployments bedient.

Schritt 6: Zuerst in Staging testen

Tun Sie das nie zuerst in Produktion. Richten Sie die 1.3-Integration in Test- oder Beta-Umgebung ein, führen Sie reale Launches aus, posten Sie echte Noten und prüfen Sie ihren korrekten Eingang. Alle Plattformleitfäden empfehlen, 1.3 vollständig in Staging zu validieren, bevor Produktion berührt wird.

Schritt 7: Umstellen und dann 1.1 abschalten

Nach bestätigtem Staging deployen Sie in Produktion. Abhängig von der Hosting-Entscheidung aus Schritt 1 werden bestehende Links automatisch aktualisiert oder benötigen Migration. Wenn 1.3 in Produktion funktioniert, entfernen Sie 1.1. Beide Versionen desselben Tools parallel zu betreiben wird nicht empfohlen und ist auf einigen Plattformen unter derselben Domain nicht erlaubt.

Risiken, die tatsächlich Probleme machen

Noten können vorübergehend aus dem Notenbuch verschwinden. Das ist für Lehrkräfte alarmierend, aber oft erwartetes Verhalten statt ein Fehler. Bei manchen Integrationen erscheinen vorhandene Noten erst wieder, nachdem Lernende oder Lehrkräfte das Tool neu starten und Konten erneut gekoppelt werden. Noten sind nicht verloren, aber ohne Vorwarnung entstehen panische Supporttickets. Kommunizieren Sie das vorher.

Doppelte oder defekte Aufgabenlinks. Migrationen lassen oft alte 1.1-Links zurück, die ins Leere zeigen. Es können doppelte Aufgaben entstehen: eine funktionierende 1.3-Version und eine tote 1.1-Version. Planen Sie die Identifikation und Bereinigung alter Links ein und sagen Sie Lehrkräften, welche sie behalten sollen.

Nutzer-IDs können sich ändern. Trotz angestrebter Inhaltskompatibilität verschieben sich Kennungen manchmal. Die unter 1.3 erhaltene User-ID kann von der gespeicherten 1.1-ID abweichen. Wenn Ihr Tool Datensätze mit der LTI-User-ID verknüpft, planen Sie beim ersten 1.3-Launch ein erneutes Koppeln alter und neuer Identität ein, sonst verwaist Historie.

Lücken bei Noten und Feedback. Manche 1.3-Integrationen zeigen sich im LMS nicht genau wie 1.1: Einreichungen erscheinen möglicherweise nicht mehr in der nativen Bewertungsansicht oder Notenbuchsymbole fehlen, obwohl die Daten korrekt sind. Testen Sie den gesamten Bewertungsablauf für Lehrkräfte, nicht nur den erfolgreichen Launch.

Schlüsselverwaltung ist laufende Verantwortung. Unter 1.1 speicherten Sie ein Secret. Unter 1.3 besitzen Sie ein Schlüsselpaar, veröffentlichen ein Keyset und müssen Schlüssel rotieren sowie den Endpunkt verfügbar halten. Fällt die Keyset-URL aus, scheitert jeder Launch bei der Signaturprüfung. Diese neue Betriebsfläche muss überwacht werden.

Der Sicherheitsreview kann am längsten dauern. Viele Institutionen leiten eine neue 1.3-Integration an Cybersecurity oder IT weiter; eventuell müssen Ihre URLs auf eine Allowlist. Die Tool-Prüfung ist oft der zeitaufwendigste Teil der Migration und liegt nicht in Ihrer Kontrolle. Beginnen Sie früh mit institutionellen Kunden, damit sie nicht den Launch blockiert.

Fazit

LTI 1.3 ist mehr Arbeit als frühere LTI-Upgrades, weil es das Sicherheitsfundament ersetzt statt darauf aufzubauen. OIDC-Login, JWT-Prüfung, OAuth-2.0-Access-Tokens und Schlüsselverwaltung sind echte Implementierungsarbeit, keine Konfiguration. Die Abkündigung ist jedoch real und Plattformen setzen sie durch. Es geht um wann, nicht ob.

Folgen Sie der richtigen Reihenfolge, testen Sie den gesamten Ablauf in Staging und kommunizieren Sie Änderungen bei Notenbuch und Links deutlich an betroffene Lehrkräfte. Teams geraten in Schwierigkeiten, wenn sie 1.3 wie ein Versionsupdate behandeln und erst in Produktion bemerken, dass sich das Sicherheitsmodell darunter verändert hat.

Ich entwickle und pflege maßgeschneiderte E-Learning-Plattformen und LMS-Integrationen für Edtech- und L&D-Teams, einschließlich LTI 1.3 und LTI Advantage. Wenn Sie eine Migration planen oder eine Integration neu bauen, unterstütze ich genau bei dieser Arbeit.