LTI® 1.3 as a Service
The standard itself is published by 1EdTech Consortium, Inc. — this is about who implements it, not what it says.
There are two ways to make an application work with LTI® 1.3. You can implement the specification, or you can put a service between your application and the learning management systems and let it speak the protocol on your behalf.
We build the second, so our view is not neutral. What follows is the comparison we would want if we were the ones choosing: what the work actually consists of, what a service removes, and what it is fair to ask before depending on one.
What implementing it yourself involves
Adding LTI® 1.3 to an application covers this in detail. In summary, to receive a launch you need:
- a login initiation endpoint, and state and nonce storage
- a launch endpoint that verifies a JWT against a fetched, cached, rotatable key set
- correct checks on
iss,aud,exp,nonceandstate, each of which is a security control rather than a formality - an account model that identifies users by platform and subject, and copes when no personal data is sent
And to use the services, a signing key, a published key set, an OAuth 2.0 client credentials flow, a token cache, and a separate implementation of Names and Roles, Assignment and Grade Services and Deep Linking.
That is the specification. The part that does not appear in any specification is that platforms differ: in the issuer they send, in whether they share one registration across institutions, in how much personal data they include, in whether they support dynamic registration, and in which services they grant per course. Those differences do not arrive during the build. They arrive one at a time, from customers, after launch.
What a service does instead
The service terminates the LTI® protocol. Institutions register with it rather than with your application; it completes the handshake, verifies the token, and redirects to your URL with a credential you exchange for the launch data:
app.get('/launch', async (req, res) => {
const idtoken = await axios.get('https://your.ltiaas.com/api/idtoken', {
headers: { Authorization: `LTIK-AUTH-V2 ${API_KEY}:${req.query.ltik}` }
})
const externalId = `${idtoken.data.platform.id}:${idtoken.data.user.id}`
// ... your session, your account model, your product
})
The services become REST calls against one API rather than three protocol implementations, and the per-platform differences are absorbed on the other side of it.
The comparison
| Implement it yourself | Use a service | |
|---|---|---|
| Time to first launch | Weeks | Same day |
| Protocol code you own | All of it | None |
| Key management and rotation | Yours | Handled |
| Per-platform quirks | Yours, discovered from customers | Handled |
| Spec changes and new services | You track and implement | Handled |
| LTI® 1.1 for institutions that still need it | A second implementation | Available on request |
| Per-launch cost | Infrastructure only | A usage fee |
| Control over edge cases | Total | Bounded by the API |
Most of the difference is work that does not distinguish your product. Nobody chooses a learning tool because its JWT verification is good; they choose it because it works inside the LMS their institution already runs, and it keeps working when that LMS changes something.
Questions worth asking any vendor
A launch sits in front of a learner, so the questions to ask are the ones you would ask of anything else in that path. Ours are answered here rather than left for you to find out later.
What happens during an incident? Our uptime commitment and how availability is measured are on the service level agreement page.
What if you need something the API does not expose? Tell us. The API grew out of what customers asked for, and adding a field to the ID Token or supporting a platform's quirk is normal work rather than a special favour.
What does moving away involve? Registrations point at whichever system terminates the launch, so leaving means implementing the protocol and asking institutions to re-register. That is true of any service in this position, and it is a fair thing to weigh up front.
When building it yourself makes sense
There are cases where it does, and they are worth naming plainly.
If LTI® is your product rather than a feature of it — you are building an LMS, a content platform, or an integration product — the protocol is core competence and belongs in house. If you need behaviour the specification does not cover, an unusual message type or a private extension, owning the code is the only way to get it. And if someone on the team has shipped LTI® before, the build is smaller than it looks from outside, though the per-platform maintenance is the part to budget for rather than the initial work.
For most teams none of those apply. LTI® is a requirement to sell into institutions, it has to work across several platforms, and it needs to work sooner than a protocol implementation takes.
What LTIAAS provides
Both sides of the protocol, as separate products.
LTIAAS Launch is the tool side: your application becomes launchable from any conformant LMS. Registrations, the handshake, verification and all three LTI® Advantage services, behind one REST API.
LTIAAS Connect is the platform side: your LMS can launch third-party tools, with LTIAAS acting as the LTI® platform on your behalf.
Both are billed per monthly active user with no monthly fee to start — pricing has the rates, and the first five active users each month are free for as long as you have them.
LTI® 1.1 is also supported. It is off by default, because a new integration should be built on 1.3, but if an institution you need to sell to runs a platform that cannot do 1.3 yet, ask us and we can enable it on your account.
Common questions
What does LTI® as a service actually mean?
A hosted service sits between your application and the LMS, performs the protocol work — the handshake, signature verification, key management and the LTI® services — and gives your application the verified result over a REST API.
Is it slower than implementing LTI® directly?
The launch involves one more hop, which is not perceptible against a handshake that already involves several redirects between the LMS and your servers. Service calls are proxied rather than made directly, which is the same trade.
What happens to my integration if I stop using the service?
You would need to implement the protocol and re-register with each institution, since registrations point at whichever system terminates the launch. That is the real lock-in to weigh, and it is worth asking any vendor about before committing.
Is building it yourself ever the right answer?
Yes. If LTI® is core to your product, if you need behaviour the specification does not cover, or if you already have the expertise in house, owning it is reasonable. The cost is that the per-platform differences become yours permanently.
Next
- How to add LTI® 1.3 to your application — what implementing it involves
- Receiving your first launch — the LTIAAS version, end to end
- Pricing
