Third-Party Cookies

There is a very important distinction to make here before we talk about how to use cookies within apaleo One / UI integration. A cookie is associated with a domain. If this domain is the same as the domain of the page you are on, the cookie is called a first-party cookie (The cookie has been set in a first-party context). If the domain is different, it’s a third-party cookie.

For example, site A (main site) loads site B (framed site) in iframe. Site B sets some cookies (e.g. store session data), to function properly. These cookies are called 3rd party cookies, as they are not set by site A.

Storage Access API

Third-party cookies are useful, many websites use them for legitimate reasons to make the best user experience possible. The issue here is, it’s also possible to abuse the third-party cookies in order to build profiles for users and track them and for this reason it has been proposed that browsers should provide a way to ask for users permission before storing cookies in a third-party context.

The Storage Access API provides a way for embedded, cross-origin content (acting within a third-party context) to gain unrestricted access to storage that it would normally only have access to in a first-party context. This API allow embedded resources to check whether they currently have access to their first-party storage and to request access to their first-party storage from the user agent. The Storage Access API can be summarized basically into two essential functions you can use:

Function name	Description
`Document.hasStorageAccess()`	You can use this function to determine if you (as a third-party) have access to your first-party cookies or not, this function returns a `promise` that resolve to `true` if you have access or `false` if you do not have access.
`Document.requestStorageAccess()`	You can use this function to request access (as a third-party) to your first-party cookies, this function returns a `promise` that resolves if you have been granted the access or rejects if access was denied

There are conditions to which you might or might not get the access to your first-party cookies, it depends on the implementation for each browser, meaning, it’s possible that Document.requestStorageAccess() rejects automatically. At the time of writing this article, only two browsers support the Storage Access API and only Apple’s Webkit engine support them with full restrictions. Apple’s Intelligent Tracking Prevention (ITP) is completely blocking access to third-party cookies, so if you are active within a third-party context you won’t be able to store cookies. For that you must make use of the Storage Access API.

What does that mean for you?

All apaleo One / UI integrations are acting as third-party, therefore if your application stores cookies, it’s possible that they will be completely purged or at least have some limitations and restrictions applied based on the browsers implementation of the Storage Access API. Based on above description we highly encourage all apps to:

Have a landing page, before you start authorization flow. The user must have landed on your website and interacted with it.
Set a cookie as a first-party. Once the user landed on your website set a cookie as a first-party otherwise the call to Document.requestStorageAccess() will be later rejected automatically.
Once your app is loaded in apaleo (as a third-party), make a call to Document.hasStorageAccess(), if it returns false, show a button/dialog to the user asking for their permission to store essential cookies.
When user clicks a button (this is very crucial), call Document.requestStorageAccess() in the event handler. Depending on the browser implementation a pop-up might appear to the user from the browser itself asking the user whether they are willing to grant you access to the first-party storage or not.

Please note that the Storage Access API at the time of writing this article still considered as experimental.

For more information you can visit these references: