This question often comes up from folks who are building HTML applications that run in a browser. They'd like the browser to connect to Cloud CMS to download content and display it. Usually this consists of things like images but also may consist of other types of content in Cloud CMS such as raw nodes, PDF files, video assets or more.
OAuth 2.0 and Access Tokens
Fundamentally, everything in Cloud CMS is secured from an access perspective using OAuth 2.0. This means that an OAuth 2.0 access token is required with every API call. Cloud CMS does not have the notion of a guest login or anonymous access. This is good from a security standpoint since it means you can audit and assert that every API call comes from a legitimate application and user. But it can also be troublesome for folks who want to surface content served from Cloud CMS into a web site.
XHR Cookies
One approach is to utilize a guest user who you create and who your browser-based HTML application authenticates as ahead of time. Thus, every call coming from the browser through XHR can pass the access token in the header and wallah, everything seems peachy. To assist with this approach, Cloud CMS writes a cookie called GITANA_TICKET to your browser session that will be exchanged along with future XHR calls. The cookie contains an encrypted version of the access token which the API will pick up on future calls. Thus, DOM elements like IMG tags and so forth will work in this model so long as the browser supports cookies.
App Server
Our recommended architecture is to have an app server in the middle (between your web/mobile app and the API). We'd recommend that for anything you're building, whether against Cloud CMS or any other API, since there are tremendous performance benefits (caching, CDN origin, etc) to having an app server anyway. It lets your front end app make a single call as well instead of lots of little calls.
The basic idea is to have the app server exposes a "public API" that can be called anonymously from the browser. The app server then talks to Cloud CMS (and any other backend services) on behalf of the anonymous user. If an image is requested, the app server retrieves the image, possibly caches it locally, and then serves it back. It does this as an "app user". In other words, the app server is logged into Cloud CMS and has an access token, but the browser does not.
The security advantages here are bountiful. For starters, your access tokens and secret keys are never exposed to the browser. Every call routes through your app server and so you have fine control over what you allow through. The greatest advantage of course is that you can reduce the number of calls from the browser to the app server tier. Ideally, you get it down to just 1 call. The app server receives that 1 call and may make lots of calls to Cloud CMS and other places in order to fulfill it. But it can do that with data-center proximity for low-latency and high throughput.
An architectural diagram of this approach is provided here:
https://www.cloudcms.com/developers/headless.html
Cloud CMS App Server
Does building an app server sound like a lot of work? Fortunately, Cloud CMS provides a free app server (built on Node.js) that you can run in the middle tier and which offers this public facing URL. You can run this locally for development purposes as well as on-premise within your data center. You can also host it in the cloud. It's available under an Apache 2.0 license and so you're free to extend it and mold it to whatever purposes suit you.
An architectural diagram of this approach is provided here:
https://www.cloudcms.com/developers/customAPIs.html
Cloud CMS also allows you to launch app servers that are hosted in the cloud. For any application that you create within Cloud CMS, you can launch a cloud hosted instance of the app server right from within the Cloud CMS user interface.
When you launch a hosted app server, you will receive a randomly-generated host name, perhaps like this:
http://https//c506a512-b6a4-4a24-b7f2-045ab8bfb9d2-hosted.cloudcms.net/
Bear in mind, that was randomly generated. The link above won't work. But if you launch an app server, yours will!
Once your hosted app server is online, you can begin to take advantage of some of the public API methods.
For example, this method will download a Node from your project:
https://c506a512-b6a4-4a24-b7f2-045ab8bfb9d2-hosted.cloudcms.net/static/node/e594e8a74c6c9a0c79a4
And this one will do the same thing using a path:
https://c506a512-b6a4-4a24-b7f2-045ab8bfb9d2-hosted.cloudcms.net/static/path/images/helloworld.jpg
What's basically happening is that the hosted app server (which uses the appuser account) is logging in as the appuser and retrieving these pieces of content on behalf of the public user. This puts you in the position of being able to limit the access rights of the appuser to content within your repository. That way, things that you don't want to be accessible publicly don't have to be.
For a better idea of all of the really cool things the Cloud CMS App Server can do for you, check out:
https://www.cloudcms.com/documentation/application-server.html