Long story short: browsers from year after year protect our privacy and security more and more. One of the side-effects is that third party cookies are starting to be blocked widely.

In a nutshell: first party cookies are cookies that are created by visited domain. Third party cookies are cookies created by a domain that is different from the visited domain. Let’s consider an example. You visit awesome.com and use an integrated plugin (it’s integrated as an iframe) from my.plugin.com. Cookies from awesome.com, static.awesome.com are treated as first-party cookies, but cookies from my.plugin.com, plugin.com are treated as third-party cookies.

Blocking details:

Authentication

How do cookies correlate with authentication? Your app can be a standalone app and it is always used as a first party but your app can be a plugin into another system as well (e.g. Trello Power-Up, JIRA plugin and etc). In this case your app is treated as third-party by browser.

There are two common approaches for authentication. Let’s review them and how they work with third-party cookies.

Stateless Authentication

Usually it does not have anything common with cookies. Token is added in each request for authentication reason. It can be added as a header or as a query parameter.

Works well for both first and third party cases because it does not use cookies at all.

Stateful Authentication

It’s implemented via session. Common approach to set session id in cookie to be able to send it automatically with every request. As an alternative option session id can be passed as a query parameter.

If query parameter is used for session id then you don’t have any issues with cookies (because you don’t use cookies). But still have issues because session id will be visible, easier for session fixation attack, can be logged by proxies because it is part of request url.

If cookies are used then you may have issues if your app is third party (you are integrated into another app on another domain). Because you may not be able to set your own session cookies.

How can it be fixed?

If it’s possible then migrate on token based authentication. Usually integration providers (e.g. Trello, JIRA and etc) give a mechanism of obtaining, storing and refreshing short-lived token. But sometimes it has issues or does not fit your system.

Another option is to fix your cookies (currently it’s possible).

Use OAuth for user authentication. Consent screen should be opened in a separate window (default approach due to click hijacking attack). In this case OAuth will be finished in that window as well and session cookie will be set as a first-party cookie. Actually the fact that the cookie was set as a first party will allow using your session cookie as a third party (it actually works now that way in Safari). Configure your cookie properly. Your session cookie should contain SameSite attribute. If this attribute is set to None then you must set Secure flag. Otherwise it will be blocked.

A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.

How can I test that cookies are supported?

It’s a common practice to show a placeholder page that cookies support is required. But it should be shown properly. If you google a lit bit about how to test then most likely you’ll find following code snippet:

But it actually does not work now for third party case (at least in Chrome). It works for first party case. The code snippet can be adjusted a little bit to support third party case as well (looks awkward but it works):

Also if OAuth flow is used then it’s better to run this check after OAuth completed. In this case completed OAuth can unblock your third party cookies.

Storage Access

It’s not related to authentication but it is still relevant to blocking third party access. As soon as third party cookies are blocked then access to local and session storage can be blocked as well. In this case I highly recommend to foresee this scenario and be ready to fallback to “in memory storage”. Simple example below:

Further Reading