How to send cookie to API on seperate domain in safari

Question

So basically with my app, I keep users access tokens in memory for the duration page load (e.g. once they refresh the token dissapears). To prevent them from having to sign in again, I have my auth server (https://api.myapp.com) set a httpOnly, secure cookie with a refresh token. This works fine for most users, however, some users are able to set custom domains, this means that the client react app is now on theirapp.com and trying to auth with my api on api.myapp.com . This still works in Chrome (latest), Firefox, and Safari Incognito, but does not work in normal safari (seems to completely ignore the refresh cookie).

What possible solutions do I have to making this work? Basically I want it so that:

1. user navigates to theirapp.com which makes a request to api.myapp.com
2. This returns a set-cookie: header with a httpOnly; secure; domain; .myapp.com refresh cookie.

I want it so that this cookie is then sent when the user refreshes and the SPA react app makes a POST request to api.myapp.com/auth/refresh. Is this possible in safari (again this works in all other browsers and even safari incognito)?

I don't want to have to resort to storing a longer lived access token in the users localStorage or a non-httpOnly cookie as that's obviously pretty vulernable to XSS.

Answer 1

When cookie A is set by api.myapp.com while the origin of the request is theirapp.com, then cookie A is treated as a third party cookie. Third party cookies were allowed by browsers until recently. Safari announced all third party cookies will be blocked by default. Both Firefox and Google will follow soon.

The suggestion from the said post which likely applies in your case is to use OAuth 2.0 authorisation. Or you could use OpenID connect (which is based on OAuth 2.0).

Answer 2

I'm not super familiar with Safari, and a quick google did not find any nice Safari-specific documentation, so this answer is generic.

Cookies are a weird choice for APIs. Cookies are for browsers; and are ideally-suited for simple HTML pages (no js) such as simple form POSTs where you just want the browser to do it for you and don't particularly care about security. REST APIs are usually designed with both browser and non-browser clients in mind, which makes cookies -- and particularly things like httpOnly; secure; domain; a really bizarre design choice. I would not be surprised at all if browsers are starting to tighten up on "cross-origin" or "third party" cookies -- which it turns out Safari is doing; see @bhorkarg's answer.

I would suggest moving your user access token out of the cookie and into a non-reserved header like Authorization: bearer which will not have the cross-origin problems you're running into (and has the added bonus as doubling as a CSRF token!)