LTI Developers - Saying goodbye to third-party cookies in 2024
LTI Developers - Saying goodbye to third-party cookies in 2024
Once the LTI launch is done and the tool is loaded in an iFrame, some tools would set a cookie for session management. This already doesn't work in Safari, but it seems as though all browsers will soon block third-party cookies.
MDN has an article called "Saying goodbye to third-party cookies in 2024". Here is the link: https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/#ho...
Google also has one called "Preparing for the end of third-party cookies". Here is the link: https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct
During the LTI launch to avoid the cookie problems, LTI client side postMessages is the recommendation, but I'm not sure if that's a secure way to store session data.
Am I correct in thinking this might become a problem and if so, does anyone have any experience in solving this (for example if someone already has a solution for Safari that would work later on when the other browsers block third party cookies)?
Concerns Regarding State Verification in LTI OIDC Without Cookie
I believe this process is fraught with potential pitfalls. Referring to section 2.7.3 of the LTI OIDC Login with LTI Client-Side postMessages, the specification states:
I see that although the state has been verified within the browser context according to the specification, there appears to be no mechanism to ensure that the client initiating the request is the same across subsequent server interactions—a functionality typically provided by cookies.
When redirecting to the server to load content, how does the server verify that the client remains unchanged? Similarly, in scenarios involving AJAX requests without a page redirect, there needs to be an established authentication method since there are no cookies available for the server to cryptographically link the browser session to an authenticated user.
My interpretation of the current specification suggests that completing the outlined steps is sufficient for authentication. However, without the ability to create a session cookie, the fundamental issue remains unresolved: establishing a cryptographic link between the browser and the server.
I've been talking to
I've been talking to Brightspace support and after weeks of trying to explain this situation I've got a reply that their devs will raise the issue at the the 1Edtech working group and they will review the cookieless OIDC standard on July 9 to assess if there is a gap in the standard. I'll post any updates on this here.
Re:Concerns Regarding State Verification in LTI OIDC Without Coo
Hi Nathan, The cookieless solution does bind the launch to the browser. The state is stored in the browser's Postmessage store (rather than the cookie store). If they want to perform server-side validation, the state value would need to be forwarded to any upstream requests to their servers. I hope this helps!
Thanks for the reply. Can you
Thanks for the reply. Can you help me understand how, from the server, I can be sure that the request came from the LMS authenticated User Agent and not a different User Agent?
i.e., with an HttpOnly Cookie on the server side, I can, with fairly high confidence, trust that the cookie wasn't forged by the front end. But I don't understand how, if I receive the state via a URL Query Parameter or in the request body, the backend would know that the UserAgent that sent the request was the same as the one authenticated by the LMS.
i.e., if an attacker trapped their request and crafted a webpage for that when a different user in a different browser navigated to it, it caused their browser to send their trapped request.
Same issue
We are currently investigating this and have the same concerns. For basic launches and deeplink launches we can require opening in a new window/tab (and turn the cookie into a first party cookie), but for creating new deeplinks we are forced to do this in an iframe. We have implemented the cookieless authentication for the initial LTI request but after that our applications session-cookie is blocked and the user is not able to navigate our tool to select the content for the deeplink. I do not see a secure solution to solve this. Ive tried to relay this concern to D2L/Brightspace but they do not understand (or dont know how to solve this themselves).
I would be really interested to learn more about solutions of others for this issue.
Re: Same issue
Hi Tom, LTI is not responsible for describing how tools and platforms work outside the LTI interaction. Therefore, our cookieless solutions do not provide any guidance for how a tool or platform should handle cookies within their own systems. That said, D2L and several other tools and platforms are actively engaged in the LTI Workgroup and have helped draft, review, and test the LTI Cookieless solution.
Hi Jacques,
Hi Jacques,
The problem lies in the creation of new deeplinks. This (at least in Brightspace) must be done in an iframe. Doing the initial launch with LTI (with our without cookies) is not an issue as long as our tool can then be used in a new window our session cookies work fine in all cases. But in the case of selecting deeplink content we are forced to run our tool in the iframe and thus our cookies become third party whether we like it or not, and then we can't use them anymore. The initial authentication is fine but the problem comes after that, using the state for the session tracking of the requests following the initial request is not as secure as having a session cookie. In my opinion this could be solved by allowing the DeeplinkingRequests to be done in a new window just as every other request. I feel like the enforcing of using iframes is arbitrary in this case.
Hi NathanMills and Tom,
Hi NathanMills and Tom,
Thank you both for your comments in this forum. By way of an introduction, I am one of the architects at 1EdTech.
The Cookieless OIDC LTI specification is currently under consultation and review, so it is not yet final. Despite this, multiple platforms and tools have already implemented it as part of their strategies for handling changes to cookie handling in browsers.
The specification clarifies how to associate the `state` with a particular browser instance using a platform-provided postMessage store. Practically, the OIDC endpoints for an LTI tool normally return a server-side REDIRECT for LTI 1.3, when the OIDC is implemented with cookies. However, with the cookieless solution, the LTI 1.3 tools need to return an HTML document with JavaScript that interacts with the postMessage store.
The scope of the specs focuses only on the 'LTI layer,' so they do not typically extend into the specifics of a tool implementation. Tools are expected to ensure secure communication between their web page and their backend for server validation.
For example, in some implementations, the server encrypts the `state` value before passing it to the HTML document in the 'init login' request. The encrypted version is stored via postMessage. During the subsequent 'Launch' endpoint, the HTML page retrieves the encrypted state value and redirects to the server. The server then compares the nonce, state, idToken, and decrypted stored state before proceeding.
I asked other tool implementors if they use similar patterns. Some use XHR requests to an endpoint with encrypted values to ensure the server-side validation of the launch request is one-time only (nonce) and associated with the same browser (state).
Yesterday, I raised this topic with the LTI Working Group to discuss whether the specification should include recommendations for implementing the subsequent requests between the HTML page and a tool's backend. This suggestion was well-received, and so they may flesh this out more explicitly before the spec is finalized.
I should re-emphasize, this is all on the tool's side. The Platform's role is to provide a browser-based store for tools to use if they wish. The tool is free to choose to select their preferred strategy for storing state, so long as it remains fixed to the brower instance. Alternative methods include partitioned cookies (CHIPS), Browser Storage APIs, or more advanced patterns with server-side state. These are implementation details for the tool and so they do not fall within the scope of the spec.
For a more detailed conversation, feel free to reach out to Jacques. 1EdTech runs bootcamps, events, and provides support to members developing LTI and other specifications.
Best regards,
Tim
Storage Access API
Hi Tim / Jacques,
Thanks for your response, I was wondering if you also looked into the Storage Access API (https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API) While I haven't tested this yet, according to the documentation it seems possible to keep using cookies with this API and it is supported by all major browsers. It would be great if the LTI spec could support this, so you have the choice to go cookieless completely or keep using cookies for both the LTI authentication and the following session in the tool.
While I understand that the cookieless LTI is a working solution (I got the LTI part to work fine). I still don't understand the requirement to do the creation of deeplinks in an Iframe.
Best regards,
Tom