Scenario validation for authenticated embeds that rely on cookies for auth

[vsr4493]

Hello, I wanted to get some inputs on a scenario for authenticated embeds w.r.t some of the privacy sandbox proposals here.

Taking https://example.net as the site URL for eg, the user authentication flow is:

• https://app.example.net redirects to an IDP for user authentication
• The user authenticates themselves on the IDP site
• The IDP redirects to https://accounts.example.net/auth/callback?code=<code>&state=<state>
• https://accounts.example.net exchanges the code for an auth token from the IDP, sets a cookie and redirects back to https://app.example.net

In a case where https://app.example.net is used as an embed, the flow changes slightly. A popup window is used (on user interaction with a login button) to complete the flow outlined above.

Issue

With 3P cookie blocking enabled, after the authentication flow is completed in the popup, the cookie set previously is no longer included with requests from https://app.example.net (iframed) which breaks authentication.

Some options I'm looking into:

FirstPartySets(FPS)

Please correct me if I'm mistaken, but I believe if https://app.example.net is a general third party embed it cannot be part of multiple first party sets due to the requirement of mutual exclusivity of domains across sets.

(StorageAccessAPI) SAA prompt

Showing users a SAA prompt early is one option to get 3P cookie access. However I see that this is auto-denied outside of a first party set going by https://groups.google.com/a/chromium.org/g/blink-dev/c/V9PzoCvIIIs.

(Cookies Having Partitioned State) CHIPS

A slightly altered auth flow where the embedded https://app.example.net can use a popup window to negotiate auth and then postMessage back the authorization code and state token. These can then be exchanged for an auth token set as a Partitioned cookie for the embed by https://accounts.example.net.

However, this proposed change to partition popups seems concerning as a partitioned popup implies that the user will not be signed in to the IDP either in the new window.

FedCM

I'm still digging around here, but any direction would be welcome!

Questions:

1. Is there a plan to allow SAA prompts even if not part of a first party set ahead of the change to disable third party cookies for 1% of Chrome users globally https://developer.chrome.com/blog/shipping-privacy-sandbox/#mode-b?
2. Are there any other options that I'm missing above and should consider?

[krgovind]

@vsr4493 We are indeed actively working on implementing a prompt-based SAA to support authenticated embeds. Our proposed approach is documented here, and we welcome your feedback on whether it satisfactorily supports your use case: https://github.com/cfredric/chrome-storage-access-api

cc @cfredric

[rowan-m]

It looks like @krgovind's answer resolves this, but please re-open if there's further discussion!