Federated Credential Management (spec, explainer, MDN, platform status, demo) is Google's proposed solution to anti-tracking features breaking federated login on some sites. It's officially in development but has been enabled in Chrome for half a year now, and other vendors seem supportive. We should investigate it as a potential CentralAuth autologin replacement that's better aligned with web trends.
|Open||None||T345245 Mitigate phase-out of third-party cookies across MediaWiki in production|
|Open||None||T345249 Mitigate phase-out of third-party cookies in CentralAuth|
|Stalled||DAlangi_WMF||T335851 Investigate the Federated Credential Management browser API|
The explainer says "If your RPs are SameParty, you may be better served by First-Party Sets." Which would be nice if there actually was a first-party sets standard, but it doesn't seem to be making much progress.
First-Party sets would also be useless to Miraheze as custom domains could take weeks to be added and need manual work. It looks like sets have to be reviewed and shipped in a chrome profile.
The Federated Credential Management API provides a standard mechanism for identity providers (IdPs) to make identity federation services available on the web in a privacy-preserving way, without the need for third-party cookies and redirects.
FedCM is already available in Google Chrome & Mozilla Firefox is already working on a prototype support for this feature to be available in their browser. Safari on the other hand has expressed interests. So the list is: Google Chrome, Firefox and Safari (which happens to be in combination, majority of where our traffic comes from).
Support for this API has been considered to be supported in more browsers as the plan moving forward.
Benefits of FedCM
FedCM generally raises the bar when it comes to authentication in web applications. It makes it relatively more difficult to carry out:
- phishing attacks,
- credential stuffing attacks,
and also is very easy to use and improves on trust-worthiness.
Due to the phasing out of cross-wiki logins with cookies, and Wikimedia projects are definitely affected by these, our projects will benefit from FedCM if we consider it as a possible solution to resolve cross-wiki logins using an IdP wiki like (login.wikimedia.org)
Drawback of FedCM
The mechanism used by identity federation (the use of an identity provider - an external/separate domain like login.wikimedia.org to login to other websites via cookies, redirects or iframes) has been abused to track users across other websites. This is because "As the user agent isn’t able to differentiate between identity federation and tracking, the mitigations for the various types of abuse make the deployment of identity federation more difficult".
Another potential drawback could possibly be that the FedCM feature is opt-in and opt-out. Meaning that users can enable and disable it. I'm not entirely sure if this feature is enabled by default but that's not the case, we'll need to notify users to enable this feature to be able to use it (which could lead to an extra overhead in browser configuration to our users). But I however think that in the near future, this will be made the default (potentially when cross site cookies have been completely disabled in all browsers including Google Chrome).
Stay posted on FedCM development
Subscribe to the development newsletter to be posted on discussions and changes to the API as it's being actively developed.
- The usage of FedCM relies on HTTPS (for live traffic) both on IdP and RP, and that will not be an issue Wikimedia already migrated all projects to the use of secure HTTP a while ago.
More to come soon...
CentralAuth as it is today uses SUL to login across all public wikis (our wiki farm) with third-party cookies.
The replacement of how CA authenticates to using the Federated Credential Management (FedCM) API could be possible since we already have a relying party (the website we want to login to - requesting user information website) and an identity provider (the website that provides user information for authentication - login.wikimedia.org for example).
One bottle neck is time, we may have to wait for browser adoption of the FedCM API because right now, only chrome has this support and other browsers have made little progress in this direction. So even if we decide to make CA adopt this authentication mechanism, we may not be able to do it today because of our users using other browsers which is not Google Chrome.
It may take a few more years for this to ripe into other browsers before we re-evaluate again and decide whether to move in this direction or not (maybe something better gets invented).
In terms of seamlessness and autologins, FedCM may not work exactly how CA works today because an actor will need to select and permission for which account to use for authentication via the API, before a token is generated for authentication. But CA does autologin on other wikis once login is successful in one of the public wikis in the wiki farm.
So because of this interaction between the user selecting a user account and permission (interacting with an interface manually), this may break the experience CA (for autologins) already gives our users, making this not so attractive with respect to what CA does today.
We may have to wait for a few more months to perceive how things materialize for FedCM on a lot more browsers and how it's used practically on many live websites before we reconsider.
The process of using FedCM would go like this:
- Wikipedia etc. calls navigator.credentials.get(), tells the browser about loginwiki
- the browser calls an API on loginwiki to get the username of the user, based on the central cookies
- the browser lets the user confirm who he is (or select it, if the identity provider supports being logged into multiple accounts at the same time, but we don't)
- the browser calls another API on loginwiki which takes the username and returns a validation token
- the browser returns the validation token to the initating website
We'd just need to build a bunch of simple REST API endpoints (the validation token API could probably just return the central session ID) and provide some data at a well-known URL.
It's somewhat hidden in the spec but FedCM does support automatic login, as long as the user has already logged in at least once manually on that wiki. So worse than the old CentralAuth flows but still better than top-level autologin. There's a demo site that shows the UX.
Per MDN FedCM is supported in Chrome, Edge and Opera. Also, Firefox apparently supports it in nightly builds so probably full support is not far.
Still, for now, the browsers supporting it are exactly the ones which do not block third-party cookies anyway, making it uninteresting in the short term.
If you're an identity provider whose RPs are within the same party as your IdP, we expect First-Party Sets may be a better option. First-Party Sets allow related domain names owned and operated by the same entity to declare themselves as belonging to the same first-party. This allows the same party's third-party cookies to work, even after third-party cookie phase-out.
First-Party Sets can't always be used. However, if your RPs are SameParty, consider using First-Party Sets.
First-party sets (T345589) would probably restore the full functionality of CentralAuth. However, other browser vendors are much less supportive of FPS than FedCM, and its current requirements seem onerous; but that's how Google imagines the future of entrerprise-style federated authentication at least.
We should probably revisit this task in a couple months, to see if browser support improved (and also whether viability of using first-party sets improved). It's definitely an option for keeping CentralAuth functional as a single sign-on system; it's too early to tell whether it is the best option.
In the meanwhile, we could maybe check if there's some use case list for FedCM and/or third party cookies (e.g. amaliev/3pcd-exemption-heuristics) where we can add CentralAuth so browser vendors are aware of Wikipedia's somewhat idiosyncratic authentication flows.