How to Become an LTI® Platform
The short answer
If you run the system learners log into and you want to launch other people's software from inside it, you are the platform, not the tool. That is the harder half of LTI®: instead of verifying a token somebody else signed, you mint and sign them, run an OAuth server, publish keys, and answer the service calls tools make of you.
Almost everything published about LTI® assumes the other side. The normative description of what a platform owes a tool is in the LTI® 1.3 specification and its implementation guide, published by 1EdTech Consortium, Inc.
Which side you are on
The vocabulary confuses people, so the test is simple: who owns the course?
If learners are enrolled in your system, and you want to embed third-party content and applications into it, you are the platform. If your product is the thing being embedded, you are the tool.
The terminology article covers the naming, including what 1.3 renamed. Worth reading first if "consumer" and "provider" are still in your head from the 1.1 era.
Products that need the platform side are usually an LMS, a training or course platform, a corporate learning system, or a publisher's delivery system that hosts courses and wants to offer a catalogue of integrations.
What the platform actually has to do
Every capability the tool side relies on, someone has to provide. That someone is you.
Mint and sign ID Tokens. For every launch, you assemble the claims — user, roles, context, resource link — and sign a JWT with your private key. The tool verifies against your published keys, so the signing has to be right or nothing launches anywhere.
Run an OIDC authentication endpoint. Tools redirect to it mid-launch. It has to validate the request parameters, enforce the registered redirect URIs, and respond with a form POST to the tool.
Publish a key set. Tools fetch your public keys to verify launches. If it stops resolving, every tool at every customer breaks simultaneously.
Run an OAuth 2.0 token endpoint. Tools authenticate with a signed assertion and ask for an access token scoped to specific services. You verify the assertion against their published key, decide what they may have, and issue the token.
Answer service calls. If you support grade services, tools will POST scores to you and expect your gradebook to change. If you support roster access, tools will ask for course membership and expect your enrolment data. If you support deep linking, tools will send you signed content selections that you have to verify and turn into activities.
Register tools. Each one needs a client ID, a deployment ID, stored endpoints, and permissions. Multiplied by every tool your customers want.
Why it is harder than the tool side
Three reasons, and they compound.
You are the trust anchor. A tool verifies signatures. A platform makes the assertions everyone else trusts, which means key management, correct claims, and correct scoping are yours. A mistake here is not a broken feature; it is a security problem in someone else's product.
You have to be right for everyone. A tool works against the platforms its customers use. A platform is used by every tool its customers pick, each written against a different reading of the specification and each with its own expectations. Tolerating that variation is most of the work.
Services are servers, not clients. On the tool side, grade passback is an HTTP call you make. On the platform side it is an API you host — with permission checks, validation, pagination, and a gradebook to actually update.
The realistic scope
Being honest about it: this is not an afternoon's work, and it is not one endpoint.
You are building an identity provider, an OAuth authorisation server, a key management story, and server implementations of two or three services — plus an administrative surface for registering tools. And you are doing it against a specification whose ecosystem of libraries and tutorials is overwhelmingly written for the other side.
The libraries that exist mostly implement the tool half. Platform-side support is thinner, less maintained, and in several languages absent entirely.
The alternative
The same build-or-buy question as the tool side, with the balance tilted further, because the platform side is more work and less well served by open source.
LTIAAS has a product for this. It handles the platform half — the authentication endpoint, token minting and signing, the key set, the OAuth server, and the service endpoints tools call — and forwards the requests your system needs to answer to a URL you control. Your LMS answers questions about your own courses and grades; it does not implement LTI®.
LTIAAS Connect covers what it does and how it fits.
Doing both
Some products are both. A training platform that hosts courses and also wants to be launchable from a customer's corporate LMS is a platform to its tools and a tool to that LMS.
That is normal and the two sides stay separate — different registrations, different keys, different direction of trust. Worth knowing early, because it is easier to keep them apart from the start than to disentangle them later.
Common questions
What is an LTI® platform?
The side that launches. An LMS is the platform; the third-party application it opens is the tool. If you run the system a learner logs into and you want to launch other people's software from it, you are the platform.
Is implementing the platform side harder than the tool side?
Considerably. The tool verifies tokens someone else signed; the platform mints and signs them, runs an OAuth server, publishes keys, and answers the service calls tools make. It is several systems rather than one endpoint.
What do I have to build?
An OIDC authentication endpoint, ID Token minting and signing, a published key set, an OAuth token endpoint with scope enforcement, and server implementations of whichever LTI® Advantage services you support.
Why is there so little written about this?
Because most of the market sells to tools. Almost every LTI® article, library and tutorial assumes you are receiving a launch rather than sending one, which makes the platform side unusually poorly documented for how much work it is.
Next
- Tool, platform, provider, consumer — which side you are on
- LTIAAS Connect — the platform side as a service
- The LTI® 1.3 security model — what you become responsible for
