Introduction
Since the Research and Education (R&E) hackathon in February last year, the Federated Credential Management API (FedCM) API has moved to the point where its basic functionality has been included in Google Chrome and most Chromium-based web browsers such as Microsoft Edge.
It’s become clearer that the main consumer of FedCM is Google themselves, specifically Google Identity Services (GIS). GIS will use it to replace their Google Sign-In platform library and newer JavaScript library for authentication. Google started migrating traffic to FedCM in November 2023 and will continue developer migration throughout 2024.
If you are a user of federated authentication for R&E, is there a compelling reason to move to FedCM? For now, there isn’t, however, future browser privacy changes might require us to rethink our long term strategy. Read on to find out more.
What is FedCM?
Google’s current authentication APIs use iframes and third-party cookies to integrate with service providers and supply user personalization. However, with the continuing deprecation of third-party cookies, Google needs another authentication solution to continue to provide this functionality. Step forward FedCM.
FedCM is a browser platform API that enables a browser mediated authentication flow different from the typical HTTP redirect based federated authentication flow we, in the R&E community, are used to. FedCM is a JavaScript API initiated by the service provider and runs within a privileged browser environment that can, amongst other things, send third-party cookies to a user-chosen identity provider; helping to regain lost functionality when third-party cookies are globally disallowed.
Is FedCM a suitable technology for use within existing research and education federations?
Not yet, maybe never. FedCM has many remaining challenges if it were to be a suitable authentication mechanism for existing R&E federations.
How will FedCM be standardized?
Standardization is a process. The FedCM API specification exists as partial implementations in two Chromium-based browsers and as a draft report for the community group, but it is not yet a web standard. The next steps are to charter a W3C Working Group to deliver the specification and ensure there are independent implementations of all the features. This scrutiny should improve interoperability and ensure FedCM is fit-for-purpose.
Does FedCM preserve privacy better than existing mechanisms?
Privacy has multiple aspects. FedCM is being developed to mitigate some risks to privacy as outlined here. Existing R&E federations already provide a privacy-preserving framework based on data minimization principles. Does FedCM preserve privacy better? Can they work in tandem? The Working Group draft charter includes a commitment to coordinate with the W3C Privacy Interest Group to guide the development of FedCM’s privacy-preserving capabilities while still supporting federated authentication and authorization flows.
Infrastructure changes
FedCM requires significant changes to identity provider software and infrastructure (e.g., new HTTP endpoints, and new authentication flows), changes to service provider authentication initiation practices (e.g., new JavaScript APIs), and is not compatible with SAML (nor is it currently compatible with OpenID Connect).
Identity provider authentication
Whilst it is not uncommon in the consumer space to stay logged into, for example, your Google account, it is common in the R&E space that the initial authentication to your organisation is initiated from the service provider. For example, a student wants to log into their virtual learning environment which redirects them to their identity provider to sign in for the first time. A way to log into your identity provider from the service provider was only added, behind an experimental flag, to FedCM in October 2023. This is supported through a popup window which displays the identity providers login page. However, this popup is unworkable if the identity provider is an authentication intermediary (an identity provider/service provider proxy), and may not provide a good mobile experience.
Multiple identity provider support
FedCM does not currently ship with multiple identity provider support, and Google only talks about the discovery problem from the perspective of a handful of consumer identity providers (e.g., a max of 9 social providers) and not the thousands of institutional identity providers we deal with in typical R&E federations. The R&E community has been actively engaging with Google on the ‘multi-identity provider‘ scale problem; however, designing a usable solution for identity provider discovery is hard, and we would not expect a solution to this in the short term (if ever).
Authentication intermediaries
Authentication intermediaries/proxies are an important and well used mechanism to support Federated SSO within R&E. However, they are not a well understood use case in consumer space authentication, and there is no clear way this should work in FedCM. Google informally acknowledge the issue but are not actively working on a solution for it.
Stability
FedCM is still evolving, with new features often picked from OAuth2.0 and OpenID Connect standards, and there are still many active and open tickets in the FedID CG GitHub repository: so we would expect the APIs to change even more during 2024 as GIS consumers start to use it.
Should the research and education community be migrating to FedCM as a replacement technology for federated authentication?
For the same reasons we cannot see FedCM as a usable technology within existing federation infrastructure, we also do not see a route to converting existing federation infrastructure to FedCM. For the most part, third-party cookie deprecation is not of concern to SAML federations other than logout—which is already hard even with third-party cookies enabled—and embedded personalized discovery buttons such as that provided by SeamlessAccess. So, is it worth tracking? Yes, there are bigger challenges on the horizon, such as mitigations for navigational tracking, which may break redirect based SSO and lead browser vendors to suggest FedCM as the solution.
Beyond FedCM
The privacy community group and navigational tracking?
With the continuing demise of third-party cookies, advertisement agencies have started exploiting another client-side method to enable cross-site tracking, namely, navigational tracking. This takes the form of bounce tracking with or without additional tracking query parameters or path variables. For example, the following, taken from the Chrome Developer Blog, shows two of the most common forms of bounce tracking:
Navigational tracking leads to the same privacy concerns for users as third-party cookie tracking. Consequently, Apple, Brave, and Mozilla already have an evolving set of navigational tracking mitigations in place. Google, whose business model, in part, relies on ad-tech, has waited until they have an alternative to third-party cookies and bounce tracking in place—their Privacy Sandbox—before starting to ship their mitigations.
Sadly, cross-site tracking and common federated SSO techniques look identical to the browser. For example (this can be even more complicated when authentication proxies are involved!):
Is it possible to distinguish between them? can the browser prevent cross-site tracking without negatively effecting (I.e., preventing) federated SSO?
Currently, Chrome intends to remove state (e.g., cookies) for sites a user visits but does not interact with inside a 45-day window — labelling them as trackers. In a basic SSO scenario, that may, for now, be reasonable, as typically you will need to authenticate to your identity provider within a 45-day window: for example, as an initial authentication, after your session has expired, authentication was forced by the service provider, or step-up authentication is needed. However, the user may never directly interact with an authentication intermediary/proxy, and browser state may repeatedly be removed. Also of concern, it is possible that the one and a half month (45 days) window becomes days or even hours. The 90-day certificate lifetime changes suggest ‘best practices’ change, and those changes are not always driven with consideration of the larger community.
If any of this were to happen, would the answer be to use FedCM instead of existing redirect-based federations? This, sadly, is not easy to answer right now.
Digital Identity Wallets?
The discussion does not end until we talk about digital identity wallets and Verifiable Credentials. Anything that happens in the federated authentication space may end up as a discussion about wallets and the impact those will have on the protocols we use, how authentication occurs (e.g. authentication credentials and or passkeys), and how attributes are transferred.
Browser vendors are becoming more involved in wallet discussions. With the web browser acting as a mediator between credential issuers (analogous to an identity provider), credential verifiers (analogous to a service provider), and user-installed wallet applications (web browsers could natively support their own wallets, Brave for example already has its own crypto wallet). New Identity Credential APIs—part of the same Credential Management APIs as FedCM—are being developed to support this within the W3C. If this happens, in the long term, will federated authentication as we know it disappear altogether?
The R&E community are actively engaged in the emerging Digital Identity Wallet field, please see this earlier blog post on the more general topic of self-sovereign identity.
Conclusion
FedCM is not usable right now either within or to replace existing R&E SAML federations. Thankfully, SAML Federations are not significantly affected by third-party cookie deprecations, of more concern are advancements in navigational tracking mitigations. Such mitigations could lead to the complete breakage of redirect federations as we know them today. If that does happen, it is possible either FedCM or Digital Identity Wallets will be directions we must pursue.