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:

Google also has one called "Preparing for the end of third-party cookies". Here is the link:

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:

2.7.3 Compare state & nonce
You are now in an HTML page with running JavaScript, where you can either make an AJAX call to receive session information or a redirect URL, or you can redirect to another page with the values as parameters.

Either way, once you've validated your id_token via the standard OIDC process and compared the state & nonce between the id_token and the platform storage values, your user is validated and can be redirected to the appropriate tool page.

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.