Navigating the Cookie-Free Future With LTI®

A Guide to Fixing Your LTI® Tool for Chrome's Third-Party Cookie Block

LTI® tools are often displayed in iFrames within LMSes. This makes for a seamless interface with the LMS, but creates challenges when Cookies are involved.

Starting in 2024, the Google Chrome web browser has started phasing in the blocking of third party Cookies. This shift is in response to growing concerns about user privacy and the need for more transparent and user-centric data practices.

info

A third-party Cookie is a Cookie that is originating from a different domain than the primary website.

Does LTIAAS Require Cookies?

No, LTIAAS has been Cookie-Free since 2022. Instead of Cookies, we store temporary launch information in the local browser sessionStorage. If a browser doesn't support this, we fall back to a new LTI® protocol (video) that allows us to store session information directly with the LMS. We default to using sessionStorage first, because not all LMSes support the the new LTI® cookie-less protocol.

What Action Is Needed Of Me?

To understand if third-party Cookie blocking will affect your LTI® tool, there are a couple of tools available to help:

1. Using Google Chrome, enable third-party cookie blocking.

   This is a quick and easy pass/fail test. If the LTI® launch pricess works and you are able to use your tool as a teacher/student, you are probably not reliant on third-party cookies.

2. Install the Google Chrome Privacy Sandbox Analysis Tool (PSAT) into Google Chrome.

   Using PSAT, you can get more insight on what Cookies your LTI® tool is reliant on and how to resolve them.

tip

When testing third-party Cookie blocking, make sure to test the deep-linking flow (if you tool uses it) as well as a launch within an iframe.

Oh No, My Tool Is Broken! How Do I Fix It?

There are many ways to resolve this issue. Here are several that we recommend to our customers:

Options That Modify Or Remove Cookies

1. Leverage Browser sessionStorage:

   If you have full control over your authentication system, you can use the web browser's sessionStorage API to store session information instead of within a Cookie. This requires JavaScript to set and retrieve the session information within the front-end.

2. Using a JWT Query Parameter:

   Upon an LTI® launch, LTIAAS send a query parameter called ltik. This is a JWT that your tool uses to login/authenticate the user. After you authenticate the user, you can append your login JWT as a query parameter to your front-end so it is always accessible. The JWT can then be sent from your front-end to your back-end every time you make a request the requires authentication.

3. Using Partitioned Cookies:

   If you have control over the Cookie that is sent, you can simply add SameSite=None; Secure; Partitioned; to the Cookie. This is called Cookies Having Independent Partitioned State (CHIPS). However this is very new. As of Feb 2024, this is only supported in Google Chrome version 100 and higher and Microsoft Edge version 114 and higher. Not Safari, Firefox, or older versions of Chrome and Edge.

When Changing Cookies Is Not Possible

You might not be able to change your tool's use of Cookies. That's OK, there is still an option. Simply open the tool in a new browser tab, instead of an iFrame. There's a couple of ways to do this:

1. Ask the LMS to always open your tool in a new tab. Most LMSes support this, but sometimes admin mistakes are made and your tool doesn't open in a new tab. So option 2 is still recommended.
2. If you detect that your tool is within an iFrame, give the user a button that opens your tool in a new tab. Here are some example JavaScript/React code snippets.

// JavaScript function to detect if the page is loaded in an iFrame
function inIframe () {
    try {
        return window.self !== window.top;
    } catch (e) {
        return true;
    }
}

// ReactJs Example Code
// When page loads, check if we are in an Iframe, and ask the user to open in a new Tab
{inIframe() === true &&
    <button onClick={() => {window.open(window.location.href);}}>Open In New Tab</button>
}

This makes the LTI® integration feel a little less magical, but it will allow your tool to continue to work, which is the most important thing.

danger

Specifically for Deep-Linking content selection: Simply opening your tool in a new tab will break the integration with most LMSes.

Handling Deep-Linking In a New Tab

Opening your tool in a new tab after a basic LTI® launch is totally fine to do. But, if you need to have your tool opened in a new tab for deep-linking, great care must be taken to not break the Deep-Linking process. Most LMSes use the iFrame postMessage API to send deep-linking data from the tool iFrame to the LMS parent window. So if you leave the iFrame, the LMS will attempt to post a message to a parent window that no longer exists, breaking deep-linking with the LMS. Here's a couple options to handle this.

1. Don't require a login for deep-linking:

   For many tools, user login is only required for a normal tool launch and getting deep-linking data can simple be authenticated with a one-off call to the LTIAAS idtoken API with no user session created. This will allow you to keep the deep-linking flow within an iFrame.

2. Use Polling or WebSockets:

   If you must open the deep-linking view in a new tab, you must keep some communication between the new tab and the existing iFrame so the the deep-linking process can be completed back in the iFrame after the content selection is completed in the new tab. There are a couple of wasy to handle this.

   1. Use iFrame Polling: This is a simple and robust solution. After the new tab is opened, the iFrame polls your tool's back-end to see if the content selection has completed in the new tab. We recommend polling once a second which creates an unnoticeable lag in most cases. Once the user completes the content selection in the new tab, the new tab stores the selection item in your tool's back-end database. We recommend using the LTIAAS-provided ltik as a database key to guarantee that no other user sessions could get mistakenly consumed by the iFrame. After the iFrame pools successfully, it then posts the form to the document body and finishes the deep-linking process.

   2. Use WebSockets: Similar to using Polling above, you can use WebSockets to make a connection between the iFrame and new tab. This is not recommended because WebSockets require more effort to ensure their reliability. But if your application already uses WebSockets, they could be reused for this purpose.

   Getting Help

   There's a lot of information to digest here, and coming up with the right solution is a challenging task. LTIAAS is here to support this transition for our customers the best we can.

tip

Contact LTIAAS support about third-party Cookies