SCORM Cloud changes to authentication cookies


As many of you already know, the fast-approaching Chrome 80 release comes with a few major changes that may require action on your part to ensure your web applications continue to operate as they did in prior Chrome versions.  This document should give you an overview and some resources giving insight into how these changes may affect your integration with SCORM Cloud.

While we at SCORM Cloud have been able to handle some of these completely under the hood (i.e. deprecation of synchronous XHR requests), the changes Chrome is making to third party cookies may require some modifications to your application.


What's the problem?

The Chrome team has decided to make some changes to the way that third party cookies are respected by the browser.  Specifically: any third party cookies MUST contain the attributes SameSite=None; and Secure;.  This will cause a problem for any applications which embed the SCORM Cloud player and connect to SCORM Cloud via HTTP rather than HTTPS.

While this is currently only an immediate issue for people using the Chrome browser, it is important to note that both Firefox and Edge browsers are planning to adopt this behavior in the future.  This is a push by all major browsers to fall in line with the Incrementally Better Cookies IETF Draft.

For some additional information about these attributes and what they mean, and what they mean to you this is a great overview explanation. Also, this article gives a little more information on when the other major browsers intend to implement these changes.


Who's affected?

The shortest, most concise answer is everyone who isn't using HTTPS exclusively in their web applications when making requests to SCORM Cloud which is embedded (such as in an iframe) in your application.  While the most immediate effects are for applications with customers who use Google Chrome, all browsers are adopting these changes in the future.



This should be as easy as ensuring that all of your communications with SCORM Cloud occur over HTTPS.  As of Chrome 76, Chrome offers some flags which allow you to enable this behavior preemptively so that you can ensure that the release of Chrome 80 on February 4th, 2020 will be appropriately prepared for and go off without a hitch. 

Additional information about the change and the development flags can be found here.


As always, if you have any questions or concerns, feel free to reach out to

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request
Powered by Zendesk