v144 · privacy · demo

SSO Without RWS

Related Website Sets let brands share cookies across brand.com, brand-help.com, brand-shop.com. With RWS removed, single sign-on must use standard mechanisms: shared parent-domain cookies for subdomains, or document.requestStorageAccess() for cross-origin embeds. This generator builds the exact Set-Cookie headers for both patterns.

RWS removal means document.hasStorageAccess() and friends no longer consider RWS membership. Cross-subdomain SSO via .example.com cookies still works fine — it never needed RWS. Cross-origin SSO now needs per-frame user activation and requestStorageAccess().

hasStorageAccess: checking…

Pattern 1 — Subdomain SSO (no RWS needed)

This is the common case. auth.example.com and app.example.com share the same eTLD+1 (example.com), so a cookie set with Domain=.example.com is visible to both. No RWS, no storage access API, no third-party cookies involved.

configure your domains

generated Set-Cookie headers

  • Fill in the form and click Generate.

Pattern 2 — Cross-origin Embed (Storage Access API)

If shop.example embeds a widget from auth.otherdomain.com, the widget frame must call document.requestStorageAccess() on user interaction to read its own first-party cookies.

step 1 — user visits shop.example

The page loads an iframe from auth.otherdomain.com. No cookies are available to the iframe yet (partitioned storage).

step 2 — user interacts with the iframe

A "Continue as Jane" button inside the iframe calls document.requestStorageAccess(). The UA shows a prompt or silently grants if the user has visited auth.otherdomain.com directly.

step 3 — iframe fetches with credentials

After storage access is granted, fetch("https://auth.otherdomain.com/me", { credentials: "include" }) sends the session cookie.

// Inside the embedded iframe (auth.otherdomain.com/widget.html)
const btn = document.getElementById("continue-btn");
btn.addEventListener("click", async () => {
  try {
    // Must be called inside a user gesture
    await document.requestStorageAccess();
    const res = await fetch("https://auth.otherdomain.com/api/me", {
      credentials: "include",
    });
    const user = await res.json();
    renderLoggedInState(user);
  } catch (err) {
    // User denied or browser disallowed — show login link
    showLoginFallback("https://auth.otherdomain.com/login?return_to=" + location.href);
  }
});

RWS approach vs. standard cookie approach

aspect RWS-based (removed) standard approach (works)
same eTLD+1 subdomains RWS set membership required Domain=.example.com cookie — no RWS
different eTLD+1 brands RWS JSON manifest in GitHub repo requestStorageAccess() per-frame + user gesture
cookie scope RWS automatically granted unpartitioned access Explicit per-frame grant — more granular
user activation Top-level page could trigger silently Must come from user gesture inside frame
CORS requirement None (first-party context granted by RWS) Origin-specific CORS headers required for cross-origin fetches
Permissions-Policy storage-access permission policy header storage-access permission policy still applicable
supported in Chrome 144+ no yes

see also