SCORM Cloud Content Protection


Content assets are protected at the web server level using a browser cookie. This means even image files, or anything else that can be requested via URL is protected against access unless the user is accessing them via the SCORM Cloud launch process.


Any request to content assets requires the requesting browser to also send a "ContentAuth" cookie, which will include the path to the course being accessed, and some other information about the launching user, such as their registration id. This cookie is set in a process of redirection by our servers during the launch process that happens as a result of calling our web service method BuildRegistrationLaunchLink. It is also signed using a hashing algorithm by our server at this time so that later we can verify that only we could have set the cookie. This is how we can ensure that a user gets a "ticket" or token to the content assets on launch, and that this ticket can only be handed out through the launch process, and hence the user can only access the course content by launching through the web service.


You can try this out and see the result yourself by launching a course on your account on our website at, copying one of the direct URL's to part of the content (like an image location for example), then leave the course, clear out your cookies (specifically CloudFrontPolicy), and paste the URL into your browser. What you'll see is an "Authorization Denied" error, sent back from our web servers. This is what any user trying to directly access your course would see if they had not gone through our launch process (which you control access to in your own application).


Determining which users will be able to launch which registrations and access which courses is left to the domain of the application integrating with SCORM Cloud, but typically access to courses would be based on the application's users and protected by a user login, as well as any other custom logic you deem appropriate.


We have seen quite a few support tickets over time when users attempt to launch a course and get a message of the type:



Authorization Required

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.



Due to how our content protection scheme works, as explained above, we can assume that typically, a problem leading the Authorization Required message is rooted in a problem either with your browser sending the "ContentAuth" cookie or with our servers authenticating the cookie. Here's a few steps you can take to try and troubleshoot the issue. 


1) Are cookies enabled on your browser? It's required that you accept cookies from in order to receive and later send the ContentAuth cookie.

2) If you're launching a dispatch package or trying to run our player or site in an iframe, do you have third party cookies enabled? 

3) Are you trying to visit a course URL directly that you launched much earlier in time? The cookie is only set on your browser when you launch through our web services, and any cookie you receive only remains valid for a limited time. Even if you accessed the course assets earlier in the day through a launch, if you try to directly access them later, you may be denied access, and you'll need to relaunch.

4) Does the course contain spaces in the course id? Although this problem should go away in the future, it looks like there may be a browser bug with Safari in which cookie paths that contain spaces (encoded as %20) are not sent with the request. In this case, you can either use another browser, such as Firefox, IE, or Chrome, or reimport the course (which will now strip spaces out of the course id to avoid this problem)

5) Still having a problem? Send us an email at and we'll get right to it, and add the solution we find to this list!

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