SameSite=None Secure requirement for cross‑site auth cookies in Safari ITP

The goal is to maintain a cross‑site authentication flow that relies on a session cookie set on a third‑party domain (e.g., api.auth‑provider.com) while the user interacts with the main application (app.example.com). The cookie is set with SameSite=None to allow cross‑origin requests, and the server returns it over HTTPS.

In local development the request originates from localhost, which is treated as a single origin so Safari’s Intelligent Tracking Prevention (ITP) does not apply. In production the two domains differ, and Safari’s ITP blocks third‑party cookies unless they satisfy the Secure attribute and are not considered tracking. ITP also caps the lifetime of first‑party cookies set via JavaScript to 7 days, and in some contexts to 24 hours, which can cause the session to expire prematurely. These rules are version‑dependent and not fully documented in the public spec.

What exact ITP heuristics determine whether a cross‑site SameSite=None cookie is accepted on a production domain? Does Safari treat authentication cookies differently from other third‑party cookies when the referring site is classified as tracking? If the cookie is blocked, is the Storage Access API a viable fallback, or must the architecture be changed to avoid third‑party domains?