Skip to content

Instantly share code, notes, and snippets.

@rexxars
Last active May 29, 2024 16:37
Show Gist options
  • Save rexxars/42d870946d82a3daa0e35b238e0b7d7a to your computer and use it in GitHub Desktop.
Save rexxars/42d870946d82a3daa0e35b238e0b7d7a to your computer and use it in GitHub Desktop.

Login issues

Situation

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.

Complication

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.

Question

How can we log user in to our service (and keep them logged in), without using cookies that browsers will block?

Answer

We're asking for advise because all of the proposed solutions (outlined below) have fairly big drawbacks compared to the current solution.

  1. 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.

  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment