How to Test an LTI® 1.3 Integration
The short answer
You cannot test an LTI® tool on its own, because a launch has to come from somewhere. So the first problem is getting a platform to launch from — and the commercial ones are expensive. Free sandboxes and self-hosted platforms solve that, and the second problem is knowing what to test once you have one.
Getting a platform to launch from
Moodle
The practical default, even if none of your customers use it. It is free and open source, self-hostable, supports dynamic registration, and can act as a platform as well as a tool — so you can test both directions without paying anyone.
There is a public sandbox that accepts LTI® tools. It resets every 24 hours, which is fine for a launch test and useless for anything you want to come back to. For sustained work, run your own.
Brightspace
D2L operates a developer sandbox with LTI® 1.3 support — useful because Brightspace is strict about exact redirect URI matching, which is worth discovering before a customer does.
Canvas
Canvas is open source and self-hosting is common, with two warnings that cost people days.
The Bitnami Canvas image on AWS does not ship with the provisions LTI® needs. A large share of "Canvas will not work with our tool" reports trace back to it.
Self-hosted Canvas needs its session cookies configured for iframes, or it bounces users back to a login screen repeatedly. Both are covered in common problems.
If you would rather not run one, Instructure's partner programme provides a hosted test instance.
Reference and conformance tools
1EdTech publishes a reference implementation and certification tooling that can act as a platform against your tool. These are the right thing for checking specification conformance — is your response shaped correctly, are you rejecting what you should reject.
saLTIre is also worth knowing about: a free, long-standing test platform that will launch your tool and show you exactly what it sent and received. It is a bare utility rather than a tutorial, and it is very good at answering "what did the platform actually send".
They are not a substitute for a real LMS. They test the specification; your customers run software that deviates from it in small ways, and those deviations are what actually breaks.
Getting the platform to reach you
The platform has to make requests to your endpoints, so localhost will not do.
Two things are needed:
A public HTTPS address. A tunnelling service that exposes your local server on a public HTTPS URL is the normal answer during development.
A stable URL, ideally. If your tunnel hands you a new address each time, every registration you made yesterday points at nothing. A reserved subdomain is worth the small cost.
What to test
A successful launch as a teacher on Chrome proves less than it feels like it does. The list below is close to the full set of things that break in production.
| Test | Why |
|---|---|
| Launch with no name or email | Platforms are not required to send them, and many do not. If your account creation needs an email, it fails at exactly those institutions. |
| Launch as a student and a teacher | Roles drive what people see, and the roles claim is a list, not a word. |
| A second registration | Two platforms at once is where tenant-separation bugs appear. Same issuer, different client ID is the case to force. |
| Safari, and Chrome Incognito | The strictest storage defaults. Third-party cookie failures show up here and nowhere else. |
| Deep linking separately | It has an extra step back to the LMS and fails where a plain launch succeeds. |
| Each service you call | Grades and roster need scopes granted per course. A tool that works in your test course may have no permissions in theirs. |
| A replayed launch | Submit the same launch twice. The second must fail. If it succeeds, your nonce checking is not doing anything. |
| An expired launch | Wait past the token lifetime and submit. It must be rejected. |
The last two matter because they are the checks that pass silently when they are broken. A launch with no replay protection works perfectly until somebody replays one — see the security model.
Testing against a platform you cannot get
Sooner or later a customer runs something you have no access to. Two things help.
Capture a real launch. Ask them for a HAR file of the failing launch. It carries the whole redirect chain, which is usually where the answer is.
Ask what their platform sends. The ID Token claims vary, and the difference between platforms is nearly always the cause. Getting the decoded token from one real launch is worth a long thread of speculation.
If you use LTIAAS
The launch itself is verified before your application is involved, so the protocol half of this list is covered — signature, nonce, expiry, issuer and audience checks all happen upstream, and the replay and expiry tests above will fail correctly without you implementing them.
What remains yours to test is everything after: whether your application copes with a missing email address, whether roles map to the right permissions, whether two institutions stay separate in your own data, and whether your own session survives the browsers your customers use.
We can also host a private Moodle server for testing if the public sandbox's 24-hour reset is a problem. Ask us.
Common questions
How do I test an LTI® integration without an LMS?
Use a test platform rather than no platform. Free public sandboxes exist, and Moodle is free to self-host. Test harnesses that emulate a platform are useful for the launch itself but will not reproduce how a real LMS behaves.
Can I test LTI® locally?
Not directly, because the platform has to reach your endpoints over HTTPS. A tunnel that gives your local server a public HTTPS address is the standard way round it.
What is the best LMS to develop against?
Moodle. It is free, self-hostable, supports dynamic registration, and can act as both a platform and a tool. It is the fastest path to a first working launch even if none of your customers use it.
What should I test beyond a successful launch?
A launch with no name or email, a student as well as a teacher, a second institution, Safari, an expired session, and each service you use. That list covers most of what breaks in production.
Next
- Why LTI® launches break without third-party cookies — the browser tests
- The LTI® 1.3 security model — what the replay and expiry tests are checking
- Common problems — test LMS options and the Canvas warnings
