LTI 1.3: Connecting Third-Party Tools to Your Learning Platform

LTI 1.3 is the 1EdTech standard that lets a learning platform launch an external tool, such as an assessment engine or simulation, and pass along who the user is and where they came from. Optional LTI Advantage services then let the tool return grades, read rosters and offer content to pick.

The launch is a short OpenID Connect login that ends with a signed token. If you run or buy a training platform, knowing those steps helps you judge whether an “LTI integration” is real, secure and worth the effort. This guide walks through the flow, the services and the checks the specification requires.

Key takeaways

• An LTI 1.3 launch is a short browser flow: login initiation, an authentication request, a signed ID token posted back, and validation by the tool.
• LTI Advantage is LTI 1.3 plus three separate services: Deep Linking, Names and Role Provisioning, and Assignment and Grade Services.
• LTI 1.3 moved away from OAuth 1.0a-style signing, and 1EdTech has deprecated the older versions.
• Most failed launches trace to a few checks: state, nonce, audience, registered redirect URI and deployment ID.
• LTI connects tools and platforms. It does not schedule sessions, take attendance or process payments.

What is LTI 1.3 and what problem does it solve?

LTI 1.3 is version 1.3 of Learning Tools Interoperability. Per its core specification, it allows learning platforms to “integrate remote tools and content in a standard way.” The platform is the system the learner logs into. The tool is the external application that supplies functionality to it.

Without a standard, every platform and tool pair needs custom code for sign-in, course context and grade return. With LTI, a tool built once can be added to any platform that supports it. Read the LTI 1.3 Core Specification for the full definitions.

Four terms recur. A registered tool is identified to the platform by a client_id. Each integration also has a deployment_id, which the spec says a platform must generate uniquely for each tool it integrates with. A context is roughly a course, and a resource link is one launch point placed inside it.

What changed from LTI 1.1?

The security model changed. The spec’s history section says 1.3 moves “away from the use of OAuth 1.0a-style signing for authentication” and adopts OpenID Connect, signed JSON Web Tokens (JWTs) and OAuth 2.0 workflows. The spec’s abstract describes 1.3 as building on 1.1 with a new security model for messages and services.

The older versions are also retired. 1EdTech’s LTI security and deprecation bulletin, last updated June 2021, says support for LTI 1.0, 1.1, 1.2 and 2.0 would end on June 30, 2022, and it names LTI 1.3 the recommended version. Some vendors still sell 1.1 connectors, so ask which version you are getting.

How does an LTI 1.3 launch work step by step?

A launch has five steps: the platform sends the browser to the tool’s login URL, the tool redirects to the platform’s authorization endpoint, the platform posts back a signed ID token, the tool validates it, and the tool shows the resource. The table below combines the core spec with the 1EdTech Security Framework.

Step	Who acts	What is sent	What the receiver must check
1. Login initiation	Platform redirects the browser to the tool’s login URL (GET or POST)	iss, login_hint, target_link_uri (all required); LTI adds optional lti_message_hint, lti_deployment_id, client_id	The tool must accept both GET and POST
2. Authentication request	Tool redirects the browser to the platform’s authorization endpoint	scope=openid, response_type=id_token, client_id, redirect_uri, login_hint, response_mode=form_post, prompt=none, nonce, state (recommended), plus lti_message_hint if one was received	The redirect_uri must be one of the registered URIs; lti_message_hint must come back unaltered
3. Token response	Platform posts to the redirect URI	state and a signed id_token that carries the LTI message and the nonce	The logged-in user must match login_hint; with no session, the platform must fail rather than ask for a login
4. Validation	Tool checks the token	Nothing sent	Signature, iss, aud, exp, nonce, then state against the browser session
5. Resource display	Tool serves the target	The resource tied to the target_link_uri claim	Rely on the claim in the token, not the earlier parameter

The prompt=none rule exists because a launch starts from a platform where the user is already signed in. The state value is bound to a CSRF token the tool sets, which is how step 4 proves the response answers a request this tool made.

What does the ID token contain?

The ID token is a signed JWT holding the standard OpenID claims plus LTI claims. For a resource link launch, the spec requires message type, version, deployment ID, target link URI, resource link and roles. The message type must be LtiResourceLinkRequest and the version must be 1.3.0.

This trimmed payload is illustrative, with made-up values:

{
  "iss": "https://platform.example.com",
  "aud": "tool-client-id",
  "sub": "a-stable-user-id",
  "exp": 1793000000,
  "nonce": "n-0S6_WzA2Mj",
  "https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest",
  "https://purl.imsglobal.org/spec/lti/claim/version": "1.3.0",
  "https://purl.imsglobal.org/spec/lti/claim/deployment_id": "d-001",
  "https://purl.imsglobal.org/spec/lti/claim/target_link_uri": "https://tool.example.com/launch",
  "https://purl.imsglobal.org/spec/lti/claim/resource_link": { "id": "link-42" },
  "https://purl.imsglobal.org/spec/lti/claim/roles": [
    "http://purl.imsglobal.org/vocab/lis/v2/membership#Learner"
  ]
}

The spec says the sub value, when present, must be stable and locally unique to the issuer. It also says a receiver must ignore contextual data it does not understand, so tools should not fail on extra claims.

What do the LTI Advantage services add to an LTI 1.3 launch?

LTI Advantage adds three services on top of the LTI 1.3 launch. 1EdTech lists Deep Linking for choosing content in a tool, Names and Role Provisioning (NRPS) for user and role data, and Assignment and Grade Services (AGS) for grades. The launch works without them; each is a separate specification.

The 1EdTech LTI page describes the trio, and each has its own spec. The table summarizes what each one does and how a training team might use it.

Service	What the spec defines	Detail to know	Possible use in training
Deep Linking 2.0	The tool receives LtiDeepLinkingRequest and returns LtiDeepLinkingResponse with chosen content items	Request settings include deep_link_return_url, accept_types and accept_presentation_document_targets; item types are link, ltiResourceLink, file, html and image; the tool must echo data if the request sent it	An instructor picks a specific simulation or quiz from a tool’s catalog and places it in a course
NRPS 2.0	The tool reads a course’s members using the context_memberships_url in the launch	Scope is contextmembership.readonly; each member has a user ID and roles; status is Active or Inactive; other attributes need the platform’s explicit consent	A tool shows a class list or sets up seats without a separate import
AGS 2.0	The tool creates line items and posts scores to the platform’s gradebook	Scopes include lineitem, result.readonly and score; scores carry activityProgress and gradingProgress	An assessment tool returns a result to the course record

The NRPS spec states that user information is not passed in the default configuration, and that a tool “should never rely on additional member attributes to be present.” Design for a user ID and roles only.

How does a tool authenticate service calls?

The tool requests an access token from the platform using the OAuth 2.0 client credentials grant, proving itself with a signed JWT instead of a secret. The Security Framework names the grant type, a JWT-bearer client assertion type and the requested scopes. Service calls then carry that token.

The platform must validate the assertion’s iss, sub, exp, aud and jti claims before checking the signature. The core spec adds that issuer and subject must both be the tool’s client_id, and that access tokens must protect all services the platform exposes.

Pro tip: Key users on issuer plus subject. Store a learner as the pair of platform issuer and sub, never as an email address. The spec only promises sub is stable within one issuer, and NRPS may not return an email at all.

How do you keep an LTI 1.3 integration secure?

Run every check the specification requires, in the tool and in the platform, and fail closed when one does not pass. Most LTI 1.3 security comes from validating the token properly and from tying each launch to the browser session that started it, not from the transport alone.

Use this list when you build or review an integration:

• Use HTTPS everywhere. The core spec requires it for messages and services.
• Validate the signature using the platform’s public key, and require an exact iss match.
• Reject unless aud contains your client_id. If there are several audiences, check azp.
• Check exp. The current time must be before it; iat may be used to reject tokens issued too long ago.
• Require a nonce. Track values already seen so a replayed token fails.
• Match state to the browser session to block cross-site request forgery.
• Use RS256. The Security Framework says other algorithms “will limit interoperability.”
• Publish a key set URL. Systems that use key sets must provide one.

Tools must also treat platforms separately. A deployment_id is unique per tool integration, so a multi-customer tool should map each issuer, client and deployment combination to one customer record and refuse anything unregistered.

Why do real LTI 1.3 launches fail?

Launches usually fail on state handling, a mismatched redirect URI, an audience or deployment mismatch, or clock drift. Each maps to one spec rule, so the error tells you where to look. The browser is the least obvious cause, because the whole flow runs through it.

The most common surprise is the state check. A tool that keeps the value in a cookie can lose it when the launch runs inside an iframe and the browser blocks third-party storage. The tool then rejects a valid launch. 1EdTech has published a client-side postMessage approach to avoid cookies, and opening the tool in a new tab also works, at some cost to the experience.

The other failures are quicker to fix. The redirect_uri must be one of the registered URIs, so a typo or a changed domain breaks the launch. A token whose aud does not list the tool’s client_id must be rejected, which points to a registration mismatch. A server clock that has drifted can make a fresh token look expired.

Pro tip: Ask for a failing launch. During a vendor evaluation, ask to see a launch with the browser’s network panel open, then one with a deliberately altered nonce or audience. A correct tool rejects the second one, and a weak one often does not.

What does a training provider gain from LTI 1.3?

A training provider gains a standard way to put third-party tools inside a learning platform, or to make its own tool launchable from customers’ platforms, without a custom integration per pair. The gain depends on which side of the connection you sit on, so decide that first.

LTI’s vocabulary is courses, instructors and learners, and its role values include Instructor and Learner. Instructor-led providers can use it wherever a platform and a tool both support it. The table maps three common situations to the LTI role and the services that matter.

Your situation	Your LTI role	Services to prioritize	Main engineering work
You run a platform and want to embed third-party assessments or content	Platform	AGS for grades; Deep Linking for content choice	An OIDC login and authorization endpoint, a public key set, a deployment record per tool, and token issuance for services
You build a tool that customers’ platforms should launch	Tool	AGS to return results; NRPS only if you need a roster	A login initiation URL, full token validation, per-customer registration and a key set
You buy a platform and need to know what it can connect to	Neither, directly	Whichever your tools need	Vendor questions and a launch demonstration

LTI does not model sessions, venues, attendance or payments. None of the services above covers them, so an instructor-led operation still needs those handled elsewhere. If you are weighing a custom build, Mundrisoft’s piece on why enterprises move to custom LMS platforms covers the integration side of that decision.

What should you ask a vendor about LTI 1.3?

Ask for specifics, because “LTI support” can mean anything from a 1.1 connector to full LTI Advantage. Six questions separate the cases:

• Which version does the integration use: 1.1 or 1.3?
• Is it a platform, a tool, or both?
• Which Advantage services does it implement, and which does a given customer enable?
• Is the product listed as certified in 1EdTech’s TrustEd Apps Directory?
• How does it keep state when launched in an iframe?
• How does it separate customers, using issuer, client ID and deployment ID?

1EdTech describes the directory as the official listing of products that have achieved its interoperability certification. A listing is a good sign, but still ask for the launch demonstration above.

What should you do next?

List the tools you want to connect and decide whether you are the platform or the tool in each case. Then write the minimum services you need, such as grade return only, and ask each vendor the six questions above in writing. Keep the answers with your evaluation notes.

If you run instructor-led programs and are comparing platforms for the operational side of a training business, SimpliTrain’s page for professional training companies describes its approach, including payments, e-commerce and SCORM content delivery. Check any vendor’s LTI support against your own list rather than assuming it.

Frequently asked questions

Is LTI 1.3 the same as LTI Advantage?

No. LTI 1.3 is the core launch specification. LTI Advantage is a bundle built on the security of LTI 1.3 that adds three services: Deep Linking, Names and Role Provisioning, and Assignment and Grade Services. A tool can support the core launch alone, so check which services a product actually implements.

Does LTI 1.3 use OAuth?

Yes, but not the OAuth 1.0a signing used by older versions. The spec says 1.3 moved away from that style and adopted OpenID Connect, signed JWTs and OAuth 2.0 workflows. The launch itself is an OpenID Connect login, and service calls use the OAuth 2.0 client credentials grant.

Is LTI 1.1 still supported?

1EdTech’s deprecation bulletin said support for LTI 1.0, 1.1, 1.2 and 2.0 would end on June 30, 2022, and that it would no longer certify legacy versions after June 30, 2021. Individual platforms and vendors may still offer 1.1 connectors, so confirm what a product supports before you rely on it.

What is a deployment ID in LTI 1.3?

It is a case-sensitive identifier a platform generates for each tool integration, up to 255 ASCII characters. Every message between platform and tool carries it alongside the client ID. A tool used by several customers can use it to tell which integration a launch belongs to.

Can a tool get a learner’s name and email through LTI?

Not by default. The NRPS spec says LTI does not pass user information in its default configuration. Names and emails depend on the agreement between platform and tool, and may need consent. Build the tool to work with only a stable user ID and role.

Do I need LTI Advantage to launch a tool?

No. The core LTI 1.3 launch works alone and gives the tool the user, role and course context. The three Advantage services are separate specifications that the platform exposes through additional claims. Add Deep Linking, NRPS or AGS only when you need content selection, rosters or grade return.