Has anyone successfully implemented cookie-based authentication with Safari/WebKit?

[DISTinTheHouse]

Hi everyone; I'm building a desktop application with Pake, using a Next.js frontend and a Django (drf-auth-kit) backend with cookie-based authentication.

Everything works correctly on:

1. ✅ Chrome
2. ✅ Edge
3. ✅ Firefox

However, authentication consistently fails on:

❌ Safari (macOS)
❌ Safari (iOS)
❌ Chrome on iOS (WebKit)

The backend is configured with:

SameSite=None
Secure
credentials: "include"

I already fixed an issue where the authentication cookie was being sent as SameSite=Lax, so that is no longer the problem.

After investigating, it seems Safari's Intelligent Tracking Prevention (ITP) treats the backend as a third-party origin and blocks the authentication cookie, even though it is correctly configured as SameSite=None; Secure.

I'm curious how others are solving authentication when building desktop apps with Pake.

Have you had success with any of these approaches?

Same root domain (frontend + backend)
Bearer tokens instead of cookies
Storage Access API
Native authentication flow
Something else?

I'd really appreciate hearing what has worked for you.

Thanks!

[darekwojciechowski]

Your diagnosis is right, and there's no config that gets around it. Safari's ITP blocks cookies from a domain the user has never visited as a first party. In a Pake window there's no "visiting" your API domain, so it stays third-party forever. SameSite=None; Secure only gets you past the SameSite check. ITP is a separate, stricter layer on top.

Two things work here.

The clean fix is same registrable domain. The API has to sit on a subdomain of the site you load, not just share a root in spirit. app.example.com for the frontend and api.example.com for the backend is fine, and set the cookie on .example.com. Safari treats that as first-party and the cookie flows. If your frontend is on Vercel and your API is somewhere else, this means putting both behind one domain, or proxying /api through the frontend host so the browser only ever sees one origin.

If you can't do that, drop cookies and use bearer tokens. In a packaged desktop app you're not exposed to the CSRF risk that pushes web apps toward cookies in the first place, and no browser privacy heuristic touches an Authorization header. With drf-auth-kit you can switch to token/JWT mode and store it in localStorage in the webview.

Storage Access API won't help either. It requires a user gesture and a prior first-party visit, which you don't have.

Quick way to confirm which one you're hitting: open the Pake window, connect Safari's Web Inspector (Develop → your app), and look at the login response in the Network tab. If Set-Cookie is present in the response but the cookie never appears in Storage, that's ITP dropping it, and the domain change is your fix.

[DISTinTheHouse]

Thanks, that makes a lot of sense.

My frontend is currently hosted on Vercel and the Django API is on a different domain, so that would explain why Safari keeps treating it as a third-party origin.

I'll try moving both behind the same registrable domain (or proxying the API through the frontend) first. If that still isn't practical for my deployment, I'll probably switch this desktop build to bearer/JWT authentication instead of cookies.

Thanks for confirming what Safari is actually doing.