LTI® 1.3 Libraries Compared
If you are implementing LTI® 1.3 yourself, you should not write the JWT handling from scratch. Several open-source libraries cover the protocol, in varying depth — measured against the specification published by 1EdTech Consortium, Inc.
This is what exists, and — more usefully — what a library still leaves for you.
What is available
| Language | Library | Covers |
|---|---|---|
| Node.js | ltijs (docs) | Launch, and the Advantage services. The most complete of the set, with an opinionated Express-shaped structure. |
| Python | PyLTI1p3 | Launch, deep linking, AGS and NRPS. Framework adapters for Django and Flask. |
| PHP | 1EdTech PHP library | The reference implementation. Complete, and closer to the specification than to a framework. |
| Ruby | Community gems | Coverage varies considerably. Check what is maintained before depending on it. |
| Java, .NET | Community projects | Fragmented. Several partial implementations, few complete ones. |
Two things to check before adopting any of them: when it last shipped a release, and whether it covers the services you need or only the launch. A library that handles the launch and nothing else leaves the larger half of the work.
What a library gives you
The cryptographic and protocol mechanics, which is the part it is most valuable not to hand-roll:
- JWT signing and verification
- Key set fetching and key selection
- The OIDC login initiation exchange
- Claim parsing into something usable
- Usually, the OAuth 2.0 client credentials flow for service calls
What it does not
This is the part worth being clear-eyed about, because it is where the time goes.
Storage is yours. Registrations, nonces, state, session data and cached tokens all have to live somewhere. Libraries define an interface and expect you to supply the implementation. Nonce storage in particular has to be correct or your replay protection does not exist.
Registration management is yours. Adding an institution, storing its issuer, client ID and deployment ID, and giving an administrator the values they need is application code and usually an admin UI.
Per-platform differences are yours. No library normalises the fact that Canvas sends an unexpected issuer, that Blackboard shares one registration across institutions, or that platforms differ in the personal data they send. Those arrive from customers, after launch.
Operations are yours. Key rotation, key set availability, certificate chains, and the fact that your key set URL being unreachable breaks every launch at every institution simultaneously.
Upgrades are yours. When the specification gains something, you wait for the library or implement it.
A reasonable rule: a library removes most of the initial build and very little of the ongoing maintenance.
Serverless is worth checking early
Several of these libraries assume a long-lived process — an in-memory key cache, a database connection established at startup, sometimes a deploy step that must run before the first request.
On a platform that suspends between requests, a cold start can reach the LTI® code before initialisation has finished, which produces failures that appear intermittent and are hard to reproduce. If you are deploying to Lambda, Cloud Functions or similar, check how the library initialises before committing to it.
The alternative
The third option is not to hold the protocol at all. A service performs the handshake and the verification and hands your application the result, which means no library, no key handling, no nonce storage, and no per-platform normalisation:
const idtoken = await axios.get('https://your.ltiaas.com/api/idtoken', {
headers: { Authorization: `LTIK-AUTH-V2 ${API_KEY}:${ltik}` }
})
The trade is a dependency and a usage cost against work you would otherwise own. LTI® 1.3 as a service covers that comparison properly, including when a library is the better answer.
Choosing
Use a library if you want to own the protocol, have somewhere long-running to host it, and someone who will still be maintaining it in two years.
Use the 1EdTech reference implementation if you are working in PHP or want to read a specification-faithful implementation to understand the flow.
Use a service if LTI® is a requirement for selling rather than something you want to maintain, or if you support several platforms and would rather not meet their differences one support ticket at a time.
Common questions
Is there an official LTI® library?
1EdTech publishes reference implementations, but there is no single official library per language. The widely used ones are community-maintained open source.
Does a library make my tool LTI® certified?
No. Certification is a conformance process run by 1EdTech against your product, not a property of a dependency. A good library makes passing more likely; it does not confer it.
What does a library not do?
Storage, registration management, per-platform differences and operations. Libraries implement the protocol; keeping registrations, sessions and keys is your application's job.
Should I use a library or a service?
A library if you want to own the protocol and have somewhere to run it. A service if LTI® is a requirement rather than something you want to maintain. The difference is ongoing maintenance more than initial effort.
Next
- How to add LTI® 1.3 to your application
- The LTI® 1.3 security model — what a library must get right
- LTI® 1.3 as a service
