Navigating Federated Authentication: the Scope of FedCM [via Federated Identity Community Group]

Many applications and services need to work through the browser to support SSO/federated login, and yet federated login and tracking tools use the same web platform features and are indistinguishable from the browser’s perspective. From cookies to navigation-based tracking, establishing controls at the user agent (aka, browser) level that still allows authentication protocols like OAuth, OIDC, and SAML to function across all their permutations is a big undertaking. 



One of the efforts underway to preserve the functionality of federated authentication is FedCM. FedCM is designed to help in federated authentication scenarios involving only two parties (or, more specifically, two origins). For those architectures that involve bouncing between multiple origins, also known as multi-hop scenarios, users may encounter a permission request to share data for each new pair-wise connection.







Simple diagram from the draft FedCM specification



FedCM's Two-Origin Focus



The Federated Identity Community and Working Groups, the groups responsible for standardizing FedCM, remain focused primarily on enabling authentication protocols, invoked in an embedded context, to function in the absence of third-party cookies. The work is (currently) focused on the use case of authentication actions between only two origins; for example, a user signing into a news site with their identity provider account. Adding additional origins takes us into the realm of navigation-based tracking mitigation, and that’s currently out of scope for FedCM. It’s worth noting that these groups are working towards consensus, but there is still quite a bit to do before we agree to the final specification. 



Authentication actions between two origins will likely cover a large number of use cases, particularly in the world of social logins using Google, Facebook, or enterprise, university, or government services. For use cases where multiple identity provider services are chained together—something often found in higher education and the enterprise—initial versions of FedCM apply only if you are using the Continuation API within FedCM, which can help address some of these more complex use cases. For example, an organization may use an MFA solution that is different from their IdP. These solutions are typically integrated using federation protocols, which often involve redirects across additional origins. The Continuation API would allow these flows to continue in a pop-up window. This pattern could also be used for some multi-hop federation use cases.



Bindings



FedCM aims to be protocol agnostic, but that doesn’t mean that the protocols don’t have to evolve to take advantage of FedCM. Aaron Parecki (Okta) is currently working on a document that will describe an OAuth binding for FedCM. This type of binding is necessary to provide FedCM with the data it needs to present the choice to the individual regarding the authentication action. 



A similar binding is necessary for SAML-based authentication flows. That work, however, is pending initiation as any further development of the SAML specification lacks a clear home; the OASIS Security Services Technical Committee (SSTC) responsible for maintaining the SAML protocol has been closed. The profile effort for SAML will need to happen in another standards organization, but grassroots efforts to define a SAML binding document could start today!



What FedCM Can Do Today



Any time the authentication process requires more than one hop to complete, regardless of protocol, FedCM is not the answer (yet). Implementors expecting FedCM to resolve navigation-based tracking will have to wait a long time while the community considers what will work best in this scenario. The community and working groups both recognize that breaking changes to URL navigation will break the web if not handled with extreme care.



The web is moving towards much stricter privacy controls. These controls require informing individuals whenever their data is being processed by a third party. If you think of that as a core requirement for the web, then the challenge shifts to the user experience of a new request for permission at each and every hop across origins. While most recognize that as a poor user experience, we have not thought of a better solution at this time. 



Continuing the Conversation



If you are interested in engaging with new ideas and possibilities for FedCM, then please join the FedID Community Group. That’s where incubation happens! For more concrete development on specific areas intended for standardization, the FedID Working Group is the place to be. The two groups work closely together, and new participants are welcome.



----------

This post sent on Federated Identity Community Group



'Navigating Federated Authentication: the Scope of FedCM'

https://www.w3.org/community/fed-id/2024/07/12/navigating-federated-authentication-the-scope-of-fedcm/



Learn more about the Federated Identity Community Group: 

https://www.w3.org/community/fed-id

Received on Friday, 12 July 2024 21:10:03 UTC