Sanity is a headless CMS. It builds into a single page application which can be hosted anywhere (my.domain-name.com). It talks to the Sanity API to fetch and mutate data (<projectId>.api.sanity.io).
To securely keep a login session for the user, we set a secure, HTTP-only cookie on the <projectId>.api.sanity.io domain after they have authenticated with an OAuth provider. Subsequent requests to the API use this cookie.
The API responds to requests with an Access-Control-Allow-Credentials header if the origin of the request is on an allowed list of origins for that project.
As browsers are working to make browsing more privacy-friendly, the way cookies are handled is changing. Our session cookies are starting to be treated as "third-party cookies" in some browsers, since the target of the request is on a different domain than the page that is sending the request.
The result of this is users not being able to log in to our service, since once they get back to the original page, the cookie is no longer respected.
How can we log user in to our service (and keep them logged in), without using cookies that browsers will block?
We're asking for advise because all of the proposed solutions (outlined below) have fairly big drawbacks compared to the current solution.
-
Require a "proxy server" running on the same domain as the single-page application, that can receive the authentication callback and store a local, secure, same-site cookie and redirect requests to our API. Drawbacks: Sanity is no longer just an SPA, but requires a (thin) server.
-
Pass on the authentication token to the client side and store it in-memory and/or persist it to localStorage or similar. Drawbacks: Potential for reading/stealing the credential and/or having to re-authenticate on every pageload.
We're hoping there is a third solution we have not yet considered.