Unravelling LTI: Solving Common Challenges in EdTech Integration

Learning Tools Interoperability (LTI) is a powerful standard that allows education platforms and tools to work together seamlessly. However, for many developers and administrators, the reality of working with LTI can be complex, particularly when navigating issues such as browser privacy updates, secure authentication flows, and tool deployment at scale.

Last week at the 2025 1edtech Learning Impact Conference, we broke down the most common LTI implementation challenges and shared hands-on strategies for solving them.

Understanding the OIDC Flow

OpenID Connect (OIDC) is essential to LTI security, but it's not always intuitive. The OIDC handshake involves multiple redirects, and it’s easy to wonder why the tool receives a request only to redirect right back to the platform after writing a cookie. At first, it may seem odd, but the OIDC flow is designed to ensure that the request initiated by the platform can only be completed by the same user who started it. This helps prevent CSRF (cross-site request forgery) attacks, but can create usability headaches.

A real-world attack vector:
Without the cookie first added during the OIDC launch, a malicious actor could capture their id_token, stop the launch, and then craft a URL to trick another user into completing the launch on their behalf. This results in one user unintentionally submitting work under another’s account, highlighting the critical need for secure OIDC handling.

The iFrame and Cookie Conundrum

LTI typically relies on iFrames to embed tools within a platform, providing users with a seamless experience within the platform. However, iframes are frequently used to track user activity across websites, enabling targeted ads. To protect user privacy, some browsers have implemented privacy protections, particularly regarding cookies.

Safari, for example, blocks third-party cookies by default in iframes. Since cookies are necessary for maintaining secure sessions in OIDC, this poses a significant problem.

Is LTI doomed? Engineers love to solve hard problems, and so no, not at all.

Workarounds and Solutions

Platform storage via postMessage: In the absence of cookies, tools can fall back on using postMessage to store data directly in the platform context. Here’s a small snippet of JavaScript to demonstrate how to interact with platform storage. (The actual implementation is only a little bit more complex. This code just illustrates the basic idea.)

javascript

CopyEdit

await this.client.send({

  subject: "lti.put_data",

  message_id: this.client.messageId("lti.put_data", key),

  key,

  value,

});

Partitioned cookies:
Platform storage is awesome, and we’ve implemented it in all the Atomic Jolt products. However, a newer browser feature, partitioned cookies, is the proper solution we’ve been waiting for. The cookies are scoped to the site that created them and, in the case of iframes, to the combined parent and site URL, preventing cross-site tracking while allowing cookies. Safari recently announced (as of version 18.4) support for partition cookies, meaning we finally have a solution that is both secure and works in all browsers.. Below is an example of how to set a partition cookie.

javascript

CopyEdit

setCookie(c, name, value, {

  path: '/',

  secure: true,

  httpOnly: false,

  sameSite: 'None',

  partitioned: true,

});

Course Copy Headaches

Tools can be stateless (like video viewers) or stateful (requiring saved settings). When copying courses, stateful tools must retain their settings—something that isn’t always automatic. This has long been and continues to be an LTI pain point. Most tools have implemented complex user interfaces that require user intervention. In the future, a combination of two new LTI standards will simplify the copy process, eliminating the need for user input. We look forward to a day when “it just works”. These solutions include:

• Platform Notification Service (PNS) to handle context copy events.
• Link and Content Services (LCS) to update or migrate content references across course copies.

Why Keep Building with LTI?

Despite the friction, LTI remains one of the best ways to build an EdTech tool that works across platforms. With one standard implementation, you can support many platforms, enabling broader adoption and a richer ecosystem.

Developer Tools and Resources

Whether you're starting fresh or scaling an existing tool, here are resources to streamline LTI development:

• LTI Bootcamp – Intro to LTI
• Ltijs – JavaScript
• Pylti1.3 – Python
• tool13demo – Java
• lti_starter_app – Ruby
• Atomic Forge – Rust
• lti-1-3-php-library – PHP
• Atomic LTI Worker – Deploy with (almost) one click

Want to build your own tool or test on a platform?

Start with the official LTI specs and then try out one of the starter apps listed above. When it comes time to test, you’ll need to set up a platform. Moodle and Canvas both have open source. You can also request a sandbox from D2L’s partner page.

Final Thoughts

The LTI standard isn’t perfect, but it’s evolving. From browser compatibility to scalable deployment, developers are finding creative ways to adapt and improve the experience. With tools like dynamic registration, starter apps, and deeper spec support, the path to building secure, interoperable EdTech tools is clearer than ever.

This blog post is adapted from a presentation by Joseph Wong (D2L) and Justin Ball (Atomic Jolt) at the 2025 Learning Impact Conference. Learn more about Atomic Jolt's LTI 1.3/Advantage Integration here.

Got questions or want to see something demoed? We’d love your feedback.