FedCM vs Storage Access API use case

[egor-limenko]

Hey! I have a use case where I'm embedding an iframe in the third-party application. This iframe can execute an SSO process in a separate popup, which is from the same domain as the iframe. SSO auth sets cookies, that are going to be considered third-party for the host app, and this flow break when Third-party cookies are disabled.

While playing around with Chrome 117 beta, I was able to handle this case with iframe using Storage Access API. Though it looks like, based on the description, FedCM proposal is aimed to handle federated identity cases affected by third-party cookies phase out, which applies to my use case. So I'm trying to understand, which approach suits better (FedCM vs SAA)? Overall it looks like Storage Access API requires less effort to implement, but FedCM is tailor made to handle "Sign with" processes like SSO. It also seems that FedCM still does not support cross-origin iframe, but Google plans to address it.

[npm1]

Good question! I don't know which one will be better for your particular scenario. If you can attend FedID CG calls, you are welcome to as we do discuss the intersection sometimes. I think the tradeoff is that SAA is more general so the user agent will likely have more generic prompts whereas FedCM is more tailored so will have a more specific federated-login prompt. I will note that there is already FedCM support for iframes on Chrome. See https://github.com/fedidcg/FedCM/blob/main/explorations/iframe_support.md for more info, feel free to give it a shot and let us know if it worked for your use case!

[egor-limenko]

@npm1 Thank you for your response! Regarding iframe support, does it make sense to update FedCM Roadmap documentation to reflect this? https://developer.chrome.com/docs/privacy-sandbox/fedcm/#roadmap It currently states that issue is known and planned to be addressed.

I'm going to further investigate FedCM and try to apply it in our case 🙏

[johannhof]

Hi @egor-limenko, I think your assessment is pretty accurate already. SAA provides a bit more flexibility, including the ability to send actual cookies vs. "credential" identifiers, but if you can live with the reduced flexibility then FedCM is definitely the ideal choice for (federated) login flows. I'd recommend giving FedCM a shot first to see if it's compatible with your site.

If you need cookie access as part of FedCM, we're thinking about auto-granting SAA based on a prior FedCM grant and would like to see interest from developers in #467.

[egor-limenko]

@johannhof Thanks for clarification, I would continue investigating FedCM and provide my feedback in the corresponding topic. Also I've read it before, and auto-granting SAA when authentication was passed via FedCM sounds quite reasonable to me

[yi-gu]

re documentation update: please check out this blog post that has all major updates since we shipped FedCM in Chrome M108. We'd also suggest subscribing to the newsletter for any future updates.

[egor-limenko]

@johannhof @npm1 Hey, there is another difference with those two technologies that I'd like to clarify: With FedCM you actually need to make changes to the IdP to make it work, which can be problematic if it's not owned by you, while with SAA you can handle by just requesting access in the embedded context (though the downside that user would have to interact with embedded context as top level one at least once). Does it sound correct or am I missing something?

[johannhof]

@egor-limenko well, the IdP itself has to make that SAA call, though we're pondering an option for enabling top-level documents to make this call on behalf of their embeds via the rSAFor API. The tricky thing here is ensuring proper opt-in by the IdP, which is why in Chrome we're currently limiting the API to First-Party Sets (which is being renamed to Related Website Sets, FYI), and still require a requestStorageAccess call (without user gesture) by the IdP iframe.

With FedCM that is definitely a requirement though, yeah.

[egor-limenko]

@johannhof So couple of things to clarify based on your answer:

1. Am I right that requestStorageAccessFor needs to be called from the top-level context (embedding site)? So if I don't have access to the top-level context implementation this option won't work for me
2. I was not considering First-Party sets for my case because, well, our embedded iframe and embedding site in reality are not first-party. With it being labeled as Related Website Sets, can it be potentially used to establish relationship even between sites that are owned by two separate companies (with mutual agreement of course, but I'm not sure what are the legal obligations here)? Also, is it enough to provide just eTLD+1 values to add relation between sites? If yes, it can potentially solve access providing for our case

[achimschloss]

With it being labeled as Related Website Sets, can it be potentially used to establish relationship even between sites that are owned by two separate companies (with mutual agreement of course, but I'm not sure what are the legal obligations here)?

A domain can only be part of a single 1p set, leaving other questions aside (to my understanding). So that is not something the would fit for you.

[johannhof]

@egor-limenko to be clear, if you don't have any way to change the site that needs the 3rd party cookie access, none of the new APIs (neither FedCM, SAA or RWS) will help you. You can't opt other sites into cross-site data sharing, to protect their security and reputation. The signal has to come from the affected site itself.

However, if you do control the site that needs to access third-party cookies in an iframe, then you could use the Storage Access API (as you seem to have done already looking at your initial comment) , potentially in combination with Related Website Sets.

Happy to give additional guidance if you want to share more details about your setup, specifically which sites in your flow you can change and where user interaction happens :)

[egor-limenko]

@johannhof Sorry if it sounded confusing, I meant that we don't have access to the top-level site that does the embedding of the iframe. We have full access to the iframe itself and it's code however.

As an update, Storage Access API proven to work in our case, however with a severe impact on UX. I will describe it step-by-step. Current flow:

1. User logs in host site
2. User sees embedded iframe which requires authentication
3. User uses SSO popout, which uses separate IdP, to authenticate in iframe
4. After authentication was finished, cookies between popup and iframe are shared and user gets authenticated So obviously steps 3 and 4 break with Third-party cookies phase out.

Now, updated flow with usage of Storage Access API:

1. User logs in host site
2. User sees embedded iframe which requires authentication
3. We have to add a new button called something like "Enable SSO"
4. This button opens a new popup, that has the same origin as embedded iframe, but as the top level context now.
5. This popup has a single button, by clicking on which user meets a condition to interact with embedded site in top level context at least once.
6. Popup closes, now by clicking regular "SSO Login" button we can successfully get access via "requestStorageAccess" function, trough the user prompt ("Allow embedded content" popup).
7. User proceeds through regular SSO flow, unpartitioned cookies shared between SSO popout and embedded iframe

As you see, when user tries to request storage access for the first time, it requires him to proceed through multiple extra steps. We consider this as one of the solutions for the problem, but at the same time from product perspective such affect on user experience is undesirable...

[egor-limenko]

So based on my undrestanding and testing, right know there are two main conditions for "Allow embedded content" popup to appear:

1. "requestStorageAccess" must be executed as a result of user action (e.g. button click)
2. User had to interact with iframe's domain as top level one's at least once

What would've helped in our case, is that one of the conditions would've been lifted (before even showing user a "Allow embedded content" popup). I understand that it may hurt the security, but still, user will be prompted to provide his consent anyway, right? So storage access would be granted only if at least one condition was met, and user allowed access to the storage. In that case we would be able to have more or less the same flow as before, at least from user perspective.

[johannhof]

This sounds a lot like the problem I presented at TPAC last week. So, in short, we're generally very aware of this usability issue and want to solve it, but we're not there yet.

[egor-limenko]

@johannhof Thanks for sharing. Will look closely for updates