Cross-site tracking and SameSite cookies with LTI

[cronek]

Now that Safari is default blocking all third party cookies and Chrome is implementing SameSite cookie restrictions as a bridge to that same thing, what is the method External Tool developers should use to launch their tool within the course frame?  Does LTI 1.3 or LTI Advantage still use a third party cookie?

[erinhmcmillan · Accepted solution]

Hi, Kelly,

I noticed that you hadn't received an update to your question. I'd recommend checking out this document: SameSite Cookies and Canvas. It has links to resources you may need, and information about what to do if you maintain an LTI tool that uses cookies. Also check out the existing comments—they may help you out as well.

Good luck!

Erin

[cronek]

Thanks, Erin,

That post from Trevor is old and only addresses the SameSite=Lax intermediate step for Chrome.  Here I am asking about the Canvas plan to support LTI within the course content frame in light of Safari, and soon all major browsers, blocking ALL third party cookies.  Is Canvas going to document the method LTI vendors should use to keep their content within the course frame.  The Canvas LTI documentation I can find is years old and predates the 3rd party security browsers are moving towards. 

It is looking like the only solution is to force an External Tool to always launch in a new window or tab, which ruins the Canvas integrated navigation.  I'm hoping Canvas comes out soon with some new documentation for developers.

Thanks, again,

~Kelly

[erinhmcmillan]

Hi, Kelly,

Thanks for the clarification, and apologies if I initially misunderstood your question. I will see what I can find out from our developers!

Erin

[brad_marshall1]

I am also interested in knowing how an LTI tool provider can have the LTI content played within the course content.

[karl]

I just posted up this article written by one of our engineers that should help. Safari 13.1 and LTI Integration

[tgrant]

I would just like to add from the school support perspective this is already happening in Chrome as well. I am frequently providing support to faculty and students alike where Google Drive integration and other core LTIs constantly request access and fail in a loop only to find that enabling third party cookies for that site is the answer. Often times major updates to the browser wipe out these settings and revert back to blocking all third party cookies again. It looks like the steps linked in karl's post are work arounds at best.

[hh-mw]

Although this question is marked "Solved", am I correct that LTI 1.3 apps are still not working in iframes with the Safari web browser, unless "Prevent cross-site tracking" is unchecked in the "Preferences -> Privacy" menu? I have it working in Chrome and Firefox with SameSite=None cookies, but the login process seems to still fail in Safari unless I uncheck that privacy option. Thanks!

[matthew_buckett]

@hh-mw That's what we've found. One workaround is that if the user has previously visited the site and had a cookie set Safari will continue to allow cookies to be set in the context of an iframe. However this is not a good solution as it doesn't lead to a nice experience for the users.

We've moved almost all our locally developed LTI 1.3 tools to work as single page applications that don't rely on cookies and use an Authorization header on requests to the server (normally containing a JWT). This seems to work reasonably well across all modern browsers.

[hh-mw]

@matthew_buckett -- thanks for the response! I agree SPA with non-cookie auth is a good way to go in the LTI apps. What about the initial OpenID Connect login from Canvas to tool -- what are you doing to match up state between the request and response? The library I use was using a cookie for this state, but I am thinking it may not be that important as long as the initial login request doesn't perform any sensitive tasks.

[matthew_buckett]

We were using a cookie for tracking the state in the LTI 1.3 launch but have switched to using session storage (https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) so that it all works in Safari. This means you need to have JavaScript enabled in the browser (as the redirects are then done in JS, but these days most of the web requires JS and if the end point is a SPA you're going to need JS anyway for it to be useful.

IMS are looking towards allowing tools to use the platform to store the state in the future and this should allow the the login initiation URL and the redirect URL to be on different domains which is common when you have different endpoints for different regions (eg US/Europe/Asia) as session storage wouldn't work in that situation (but locally we don't have that problem as we use the same domain). I don't think Canvas supports this yet, but would expect it to as lots of tool vendors have this problem. There's a talk on this from IMS: https://www.youtube.com/watch?v=60QY7HxPenk

The reason you want to validate the state is so that a user can't be tricked into launching a LTI tool as a different user. If the redirect doesn't match the state with the login initiation then a user could be tricked into using a LTI as a different user (eg submitting an assignment as another user)

For some LTI tools it may be that you just say this is an acceptable risk and don't validate the state, but watch out for someone coming along in 2 years, copying the patterns you've developed and not realising there are security implications that didn't matter for the original tool, but are serious for the new one.