Auth Flows in a Partitioned World

Back in 2019, I explained how browsers’ cookie controls and privacy features present challenges for common longstanding patterns for authentication flows. Such flows often rely upon an Identity Provider (IdP) having access to its own cookies both on top-level pages served by the IdP and when the IdP receives a HTTP request from an XmlHttpRequest/fetch or frame embedded in a Relying Party (RP)‘s website:

These auth flows will fail if the IdP’s cookie is not accessible for any reason:

  1. the cookie wasn’t set at all (blocked by a browser privacy feature), or
  2. the cookie isn’t sent from the embedded context is blocked (e.g. by the browser’s “Block 3rd Party Cookies” option)
  3. the cookie jar is not shared between a top-level IdP page and a request to the IdP from the RP’s page (e.g. Cookie Partitioning)

While Cookie Partitioning is opt-in today, in late 2024, Chromium plans to start blocking all non-partitioned cookies in a 3rd Party context, meaning that authentication flows based on this pattern will no longer work. The IdP’s top-level page will set the cookie, but subframes loaded from that IdP in the RP’s page will use a cookie jar from a different partition and not “see” the cookie from the IdP top-level page’s partition.

What’s a Web Developer to do?

New Patterns

Approach 1: (Re)Authenticate in Subframe

The simplistic approach would be to have the authentication flow happen within the subframe that needs it. That is, the subframe to the IdP within the RP asks the user to log in, and then the auth cookie is available within the partition and can be used freely.

Unfortunately, there are major downsides to this approach:

  1. Every single relying party will have to do the same thing (no “single-sign on”)
  2. If the user has configured their browser to block 3rd party cookies, Chromium will not allow the subframe to automatically/silently send the user’s Windows credentials. (TODO: I don’t remember if clientcert auth is permitted).
  3. Worst of all, the user will have to be accustomed to entering their IdP’s credentials within a page that visually has no relationship to the IdP, because only the RP’s URL is shown in the browser’s address bar. (Many IdP’s use X-Frame-Options or Content-Security-Policy: frame-ancestors rules to deny loading inside subframes).

I would not recommend anyone build a design based on the user entering, for example, their password within

If we take that approach off the table, we need to think of another way to get an authentication token from the IdP to the RP, which factors down to the question of “How can we pass a short string of data between two cross-origin contexts?” And this, fortunately, is a task which the web platform is well-equipped to solve.

Approach 2: URL Parameter

One approach is to simply pass the token as a URL parameter. For example, the website’s login button does something like:'$1', 'blank');

In this approach, the Identity Provider conducts its login flow, then navigates its tab back to the caller-provided “return URL”, passing the authentication token back as a URL parameter. The Relying Party’s AuthSuccess.aspx handler collects the token from the URL and does whatever it wants with it (setting it as a cookie in a first-party context, stores it in HTML5 sessionStorage, etc). When the token is needed to call an service requiring authentication, the Relying Party takes the token it stored and adds it to the call (inside an Auth header, as field in a POST body, etc).

One risk with this pattern is that, from the web browser’s perspective, it is nearly indistinguishable from bounce tracking, whereby trackers may try to circumvent the browser’s privacy controls and continue to track a user even when 3rd party cookies are disabled. While it’s not clear that browsers will ever fully or effectively block bounce trackers, it’s certainly an area of active interest for them, so making our auth scheme look less like a bounce tracker seems useful.

Approach 3: postMessage

So, my current recommendation is that developers communicate their tokens using the HTML5 postMessage API. In this approach, the RP opens the IdP and then waits to receive a message containing the token:

//'', '_blank');

window.addEventListener("message", (event) => {
    if (event.origin !== "") return;
    // ...

When the authentication completes in the popup, the IdP sends a message to the RP containing the token:

function returnTokenToRelyingParty(sRPOrigin, sToken){
    window.opener.postMessage({'authToken': sToken}, sRPOrigin);

Approach 4: Broadcast Channel (Not recommended)

Similar to the postMessage approach, an IdP site can use HTML5’s Broadcast Channel API to send messages between all of its contexts no matter where they appear. Unlike postMessage (which can pass messages beween any origins), a site can only use Broadcast Channel to send messages to its own origin. BroadcastChannel is widely supported in modern browsers, but unlike postMessage, it is not available in Internet Explorer.

While this approach works well today:

  • it doesn’t work in Safari (whether cross-site tracking is enabled or not)
  • it doesn’t work in Firefox 112+ with Enhanced Tracking Protection enabled
  • Chromium plans to break it soon; preview this by Enabling the chrome://flags/#third-party-storage-partitioning flag.

Approach 5: localStorage (Not recommended)

HTML5 localStorage behaves much like a cookie, and is shared between all pages (top-level and subframe) for a given origin. The browser fires a storage event when the contents of localStorage are changed from another context, which allows the IdP subframe to easily detect and respond to such changes.

However, this approach is not recommended. Because localStorage is treated like a cookie when it comes to browser privacy features, if 3P Cookies are disabled or blocked by Tracking Prevention, the storage event never fires, and the subframe cannot access the token in localStorage.

Furthermore, while this approach works okay today, Chromium plans to break it soon. You can preview this by Enabling the chrome://flags/#third-party-storage-partitioning flag.

Approach 6: FedCM

The Federated Credentials Management API (mentioned in 2022) is a mechanism explicitly designed to enable auth flows in a world of privacy-preserving lockdowns. However, it’s not available in every browser or from every IdP.


You can see approaches #3 to #5 implemented in a simple Demo App.

Click the Log me in! (Partitioned) button in Chromium 114+ and you’ll see that the subframe doesn’t “see” the cookie that is present in the popup:

Now, click the postMessage(token) to RP button in that popup and it will post a message from the popup to the frame that launched it, and that frame will then store the auth token in a cookie inside its own partition:

We’ve now used postMessage to explicitly share the auth token between the two IdP contexts even though they are loaded within different cookie partitions.


The approaches outlined in this post avoid breakage caused by various current and future browser settings and privacy lockdowns. However, there are some downsides:

  1. It requires effort on the part of the relying party and identity provider
  2. By handling auth tokens in JavaScript, you can no longer benefit from the httponly option for cookies


Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ Microsoft 2001-2012, and 2018-2022, working on Office, IE, and Edge. Now a SWE on Microsoft Defender Web Protection. My words are my own, I do not speak for any other entity.

5 thoughts on “Auth Flows in a Partitioned World

  1. 1. You still don’t get SSO, right? User has to manually log in?
    2. Presumably the partitioned storage will also apply to all other non-cookie storage too, like indexeddb and local storage?
    3. Does this rely on browsers not considering a page opened via to be 3P relative to the page that opened it & applying the same restrictions they would if you it was opened via iframe?
    4. Actually, why does the even work? Unless you’re asking a user to click a sign-in link that opens the window, popup blocker gonna smite. Oh jeez that’s what you’re saying.

    The requirement for manual login flows is going to be very painful for _applications_ hosted as children. I think you’ll start seeing more apps moving to “just load my javascript into your page” models, increasing the risk to the parent page.

    1. 1. In theory, you could still have SSO, insofar as the RP opens the IP, which has access to its own data and may automatically return an auth token without asking the user to do anything.

      2. Someday (likely soon) other web platform storages will be partitioned, like cookies will be and HTTP cache already are. As of today, localStorage and indexedDB aren’t partitioned (unless you Enable chrome://flags/#third-party-storage-partitioning), and I’ve updated the demo with using localStorage and the |storage| event to synchronize the token between the IP top-level page and the IP subframes. Notably, other browser features (3rd Party Cookie toggles, Edge Tracking Prevention) /may/ block access to sessionStorage in 3P contexts.

      3. Browsers do not treat top-level as a 3P in the context of the opener, and it would be extremely challenging to change that.

      4. Yes, a popup-blocker could interfere here if the new window were not invoked in response to a user-gesture. (That’s not new).

      With regard to “just load my javascript into your page” — this model obviously has lots of security risks, and it also doesn’t typically work-around the problem of auth flows (since even “first party” script contexts still won’t have access to a “third party” identity.

  2. Curious if a combination of partitioned cookies (CHIPs) would work with “Approach 3” if we still want `httpOnly` cookies instead of storing the token client side?

    For eg,
    1. Iframe for redirects to IDP in a new tab
    2. User goes through the sign-in flow on the IDP site, and is then redirected to
    3. uses window.opener.postMessage to send the code to itself in the iframe.
    4. In the iframe, sends this to its own server which exchanges the code for a token from the IDP and sets a partitioned httpOnly cookie that can now authenticate the frame in a 3rd party context.

    1. I think that works, in general, so long as the subframe’s cookie is partitioned. I’ve added this to the demo app: if you use PostMessage from the IDP back to the frame, the frame will try to set a cookie on itself and if the set fails (e.g. due to 3P Blocking) it’ll try setting the cookie with the Partitioned attribute.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: