Is LTI® Single Sign-On?
The short answer
Not quite, though it covers the same need in one specific situation. An LTI® launch authenticates a user into one tool, from one course, on one click — no password, no separate login. But it cannot be started from your side, and it establishes nothing outside that launch. It is closer to a signed introduction than to an identity system.
What it does give you
A launch arrives with a signed token asserting who the user is, verified against the platform's published keys. So you get authentication without a credential: the learner clicks a link in their course and is in your product, already identified.
Under LTI® 1.3 the exchange is built on OpenID Connect, which is why it feels like SSO — it is genuinely the same family of technology.
For a product whose users always arrive from an LMS, that is the whole requirement. You never build a login page, never store a password, and never run a reset flow.
Where it stops
It is always platform-initiated. There is no way for your application to start a launch. A user landing on your homepage cannot be signed in through LTI® — the protocol has no flow for it.
It authenticates one launch, not a session. The token proves who arrived. How long they stay signed in is entirely your decision, and the launch does not maintain it.
It does not span applications. Signing into your tool from a course does not sign the user into anything else of yours. There is no shared session, no logout propagation, no way to know they have left.
The identity is scoped to the platform. The sub claim identifies a user
within that issuer. The same person at two institutions is two identities, and
correctly so.
| LTI® | SAML / OIDC SSO | |
|---|---|---|
| Who starts it | The platform, always | Either side |
| What it establishes | One launch | A session across applications |
| Carries course context | Yes | No |
| Enables grades and roster | Yes | No |
| Works from your login page | No | Yes |
That table is the real answer: they overlap on authentication and diverge everywhere else. LTI® carries course context that no SSO protocol does — which course, which activity, what role — and that context is what the services depend on.
When you need both
You need a real SSO protocol alongside LTI® when users reach your product by more than one route.
The common shape: learners arrive by launch, but administrators and instructors also log in directly to configure things. The launch handles the first group; SAML or OIDC handles the second.
That raises the question that actually costs time: how do you know they are the same person?
Account linking is the hard part
The temptation is to match on email address. It is available, it looks unique, and it is wrong.
Addresses get reused when staff leave, changed when people marry, and shared on departmental accounts. And many platforms send no email address at all, so the match is unavailable exactly where privacy matters most.
1EdTech's own guidance on
selecting a user ID reaches the
same conclusion: the durable identity from a launch is the issuer plus the sub
claim. Store that pair as a link to your own user record. When someone arrives by launch and
you have no record of that pair, you have two options and should pick one
deliberately:
Create an account automatically. Fastest, and correct for tools where the launch is the only route in. Design for a missing name and email.
Ask them to connect an existing account. Show a one-time screen where the user signs in the ordinary way, and store the link. More friction, once, and it is the right answer whenever the same human has a direct account too.
Whichever you choose, the identifier you store is the pair, not the email.
What LTIAAS gives you
Every launch is verified before your application sees it, and your endpoint receives the launch data — user, roles, course, and which services are available. The identity is there and already proven:
const idtoken = await axios.get('https://your.ltiaas.com/api/idtoken', {
headers: { Authorization: `LTIK-AUTH-V2 ${API_KEY}:${ltik}` }
})
// idtoken.data.user, .platform, .launch, .services
What stays yours is what SSO would also have left you: the session, the account link, and authorisation inside your product. LTIAAS proves who arrived; it does not decide what they may do once inside.
The launch and SSO guide walks through the implementation.
Common questions
Is LTI® single sign-on?
Not quite. It authenticates a user for one launch into one tool from one course, which covers the same need in that context. It is not a general SSO system — there is no way to start from your own login page and no session shared across applications.
Do I still need SAML or OIDC if I support LTI®?
Only if users need to reach your product outside the LMS. If every route in is a launch, LTI® is enough. If they also log in directly, you need something else for that path and a way to connect the two identities.
Can a user start at my application and get signed in through LTI®?
No. LTI® launches are always initiated by the platform. There is no tool-initiated flow, which is one of the clearest differences from a real SSO protocol.
Is the identity from an LTI® launch trustworthy?
Yes, if you verify the token. It is signed by the platform and verified against its published keys. The caveat is scope — the identifier is meaningful within that platform, not globally.
Next
- What is LTI® 1.3? — the launch sequence
- The LTI® 1.3 security model — why the identity can be trusted
- Launch and SSO guide
