Migrating From LTI 1.1 to LTI 1.3: A Practical Guide for Tool Builders
June 17, 2026 · 7 min read
If you've built an e-learning tool that plugs into an LMS, there's a deadline quietly bearing down on you. LTI 1.1, along with 1.0 and 1.2, has been formally deprecated by 1EdTech, the body that maintains the standard. The major platforms have made their position clear: LTI 1.3 is becoming the minimum requirement for any tool that exchanges personal or sensitive student data. If your integration still runs on 1.1, it's now a migration item on a clock, not a someday-maybe.
The good news is that the migration is well understood and the path is documented. The bad news is that 1.3 isn't a version bump. It's a different security model, and treating it like a small upgrade is how teams end up with broken launches and missing grades in production. This guide walks through what actually changed, the migration steps in order, and the specific things that bite people along the way.
What actually changed between 1.1 and 1.3
For most of LTI's history, new versions just added features. Everything was additive, so upgrading was painless. 1.3 broke that pattern. The payload format and the entire security model changed, which is why this is the first version jump that requires a real migration rather than a quiet swap.
Here's the core of it. LTI 1.1 authenticated messages using OAuth 1.0a-style signing: a shared consumer key and secret known to both sides, used to sign requests with an HMAC-SHA1 signature. It worked, but it's a shared-secret model, and shared secrets carry real replay and substitution risks if they leak.
LTI 1.3 throws that out and adopts a modern stack built on industry standards: OpenID Connect for the login handshake, JSON Web Tokens (JWTs) signed with asymmetric keys for message integrity, and OAuth 2.0 bearer tokens for service calls. Instead of both sides sharing one secret, the platform signs messages with a private key and publishes the matching public key at a URL. Your tool fetches that public key and uses it to verify that a launch really came from the platform.
That single change ripples through everything:
The message itself is different. In 1.1, a launch was a flat set of POST parameters plus a signature. In 1.3, that launch is encoded as a signed JWT, with the data organized into structured "claims" rather than flat parameters.
The configuration is different. In 1.1, a launch URL plus a key and secret were enough to connect the two systems. In 1.3, that's no longer sufficient. You now exchange a set of URLs and identifiers during a registration step, and the platform assigns your tool a client_id and a deployment_id.
The services are different. Grade passback, roster retrieval, and deep linking now run under the umbrella of LTI Advantage, which is only available on 1.3. Each service call requires your tool to first obtain an OAuth 2.0 access token by presenting a signed JWT, rather than reusing the old shared secret.
So you're not editing a config file. You're implementing OIDC login, JWT validation, key management, and OAuth 2.0 token handling. That's the real scope.
The migration, step by step
The order here matters. Each step assumes the previous one is done and verified.
Step 1: Confirm the platform supports 1.3 and decide your hosting approach
Before anything else, confirm the LMS your customers use supports LTI 1.3 (all the major ones do now: Canvas, Moodle, Brightspace, Blackboard). Then make a decision that affects everything downstream: will your 1.3 tool live at the same domain as your 1.1 tool, or a different one?
This matters because some platforms automatically upgrade existing course links when you deploy the 1.3 version at the same fully-qualified domain name. If you move to a new domain, you may need a link-migration step so existing course links and gradebook columns keep working. Decide this early, because changing it later means redoing configuration.
Step 2: Implement the OIDC login initiation flow
LTI 1.3 launches start with a third-party-initiated OpenID Connect login, which exists to protect against cross-site request forgery. The platform calls your tool's OIDC login endpoint first. Your tool responds by redirecting back to the platform's authorization endpoint with a state value (which you also store, typically in a cookie) and a nonce.
Build and expose this login endpoint. The state you generate here is what you'll check in the next step to confirm the launch that comes back is the one you started.
Step 3: Receive the launch and validate the JWT
The platform builds the id_token (the JWT containing the launch data) and auto-submits a form POST back to your tool's redirect URI. When that POST arrives, your tool does three things in order:
First, check that the returned state matches what you stored. If it doesn't, reject the launch.
Second, unpack and validate the JWT signature. A JWT is three Base64 sections separated by dots: a header (which names the key ID and signing algorithm), the payload (the claims), and the signature. You fetch the platform's public key (using the key ID from the header) from its published keyset URL and verify the signature against it.
Third, validate the claims: confirm the issuer, the audience (client_id), the nonce, and expiry are all what you expect. Only after all of that do you trust the launch and read the user, course, and resource information from the claims.
Step 4: Re-implement your services as LTI Advantage
If your tool does grade passback, reads the course roster, or supports content selection, those are now LTI Advantage services and they work differently. Before calling any of them, your tool requests an OAuth 2.0 access token from the platform's token endpoint by sending a signed JWT client assertion. You get back a bearer token, and you use that token to call the service.
The three common services:
Assignment and Grade Services (AGS) for posting grades back to the gradebook. Names and Role Provisioning Services (NRPS) for retrieving the course roster. Deep Linking for letting an instructor pick specific content from your tool to embed in their course.
Each one needs the access-token step in front of it. This is usually the part that takes the most new code.
Step 5: Register your tool with the platform
Registration is the new handshake that replaces the old key-and-secret exchange. You provide the platform with your tool's details: the domain, the OIDC login URI, the redirect URI(s), and your public keyset URL. The platform gives you back the client_id, the deployment_id, its authentication and token endpoints, and its public keyset URL.
Store all of these. A launch in 1.3 is uniquely identified by the combination of issuer, client_id, and deployment_id, and you'll need all three to correctly match an incoming launch to the right configuration, especially if one tool serves multiple platforms or multiple deployments.
Step 6: Test in a staging environment first
Never do this first in production. Stand up the 1.3 integration in the platform's test or beta environment, run real launches, post real grades, and confirm they land correctly. The strong recommendation across every platform's guidance is to fully validate 1.3 in staging before touching the production environment.
Step 7: Cut over, then decommission 1.1
Once 1.3 is verified in staging, deploy to production. Depending on your hosting decision from step 1, existing links may upgrade automatically or may need the migration step. After the 1.3 version is confirmed working in production, remove the old 1.1 configuration. Running both versions of the same tool side by side is not recommended and, on some platforms, not even allowed at the same domain.
The watchouts that actually cause problems
These are the things that don't show up until they've already broken something.
Grades can temporarily vanish from the gradebook. This is the most alarming one for instructors, and it's often expected behavior rather than a bug. On some integrations, after migration the existing grades disappear from view until a student or instructor relaunches the tool to re-pair accounts. The grades aren't lost, but if nobody warned the instructor, you'll get panicked support tickets. Communicate this before you migrate, not after.
Duplicate or broken assignment links. Migrations frequently leave behind the old 1.1 assignment links, which now point at nothing. You may see duplicate assignments, one working 1.3 version and one dead 1.1 version. Plan to identify and clean up the old broken links as part of the cutover, and tell instructors which ones to keep.
User IDs may change. The spec aimed for content backward-compatibility, but in practice some identifiers shift. The user ID your tool receives in 1.3 can be a different value than the one you stored under 1.1. If your tool keys user records on the LTI user ID, plan for a re-pairing step where users link their old and new identities on first 1.3 launch, or you'll orphan their history.
Feature gaps in how grades and feedback surface. Some 1.3 integrations don't behave identically to their 1.1 predecessors inside the LMS. There are documented cases where submissions stop appearing in the native grading interface, or gradebook score icons no longer show, even though the underlying data is fine. Test the full instructor grading workflow, not just whether a launch succeeds, before you call it done.
Key management is a new ongoing responsibility. Under 1.1 you stored a secret and forgot about it. Under 1.3 you own a private/public key pair, you publish a keyset, and you're responsible for rotating keys and keeping that endpoint available. If your keyset URL goes down, every launch fails signature validation. This is new operational surface area that has to be monitored.
The security review can be the slowest part. Many institutions route a new 1.3 integration through their cybersecurity or IT department, and they may need to allowlist your URLs. Vetting the tool is often the single most time-consuming part of the whole migration, and it's outside your control. Start that conversation with your institutional customers early so it isn't the thing holding up your launch.
The bottom line
LTI 1.3 is more work than any previous LTI upgrade because it replaces the security foundation rather than adding to it. OIDC login, JWT validation, OAuth 2.0 access tokens, and key management are all real implementation work, not configuration. But the deprecation is real and the platforms are enforcing it, so this is a question of when, not whether.
Do it in the right order, test the full workflow in staging, and over-communicate the gradebook and link changes to the instructors who'll be affected. The teams that get burned are the ones who treat 1.3 like a version bump and discover the security model changed underneath them in production.
I build and maintain custom e-learning platforms and LMS integrations for EdTech and L&D teams, including LTI 1.3 and LTI Advantage implementations. If you're planning a migration or building an integration from scratch, that's the kind of work I help with.
Your learning product deserves its own platform.
If you want to deliver a learning experience built around your product, your learners, and your goals, you are in the right place. We build platforms that give you the control and flexibility to grow without limits.