Investigate the Federated Credential Management browser API
Open, Stalled, Needs TriagePublic
Actions

Description

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.

It seems to build on top of the Credential Management API (spec, web.dev, MDN, caniuse, WWCDT) so we should look into that as well.

Related Objects
Search...

Status	Assigned	Task
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
Open	ArielGlenn	T359947 Test cross-domain authentication with Federated Credentials Management API

Event Timeline

Tgr created this task.May 3 2023, 12:01 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 3 2023, 12:01 PM

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.

Tgr mentioned this in T252244: CentralAuth extension: Code stewardship review.May 3 2023, 12:14 PM

KStoller-WMF subscribed.May 4 2023, 3:36 PM

RhinosF1 subscribed.May 21 2023, 5:29 PM

In T335851#8823395, @Tgr wrote:

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.

R4356th subscribed.May 21 2023, 5:39 PM

dmehus subscribed.May 21 2023, 6:45 PM

Tgr mentioned this in T345249: Mitigate phase-out of third-party cookies in CentralAuth.Aug 30 2023, 1:37 PM

Tgr claimed this task.Sep 4 2023, 6:09 PM

Tgr added a project: MediaWiki-Platform-Team.

Tgr moved this task from Inbox, needs triage to Current Sprint on the MediaWiki-Platform-Team board.

DAlangi_WMF subscribed.Sep 4 2023, 7:59 PM

Tgr added a parent task: T345249: Mitigate phase-out of third-party cookies in CentralAuth.Sep 5 2023, 11:40 AM

Overview

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.

This includes a JavaScript API that enables the use of federated authentication for activities such as signing in or signing up on a website.

Browser Support

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".

NOTE: I think one way that we can already mitigate this drawback is that Wikipedia is a server farm and we're logging into our projects only with such mechanism and not to be used to login to websites outside of the Wikimedia projects.

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).

NOTE: There seems to be however a mitigation for this based on a relying party (RP). If FedCM is disabled, there is a non-FedCM sign-in process to still authenticate using the IdP.

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.

Notes

The use of cookies for cross-site logins is being phased out in Google Chrome and other browsers and by 2024, support for this will be completely removed from Google Chrome.
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...

Xover subscribed.Sep 8 2023, 7:23 AM

pmiazga reassigned this task from Tgr to DAlangi_WMF.Sep 11 2023, 1:30 PM

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).

Notes

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.

See

Screenshot 2023-09-26 at 10.28.25 AM.png (1×1 px, 164 KB)

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.

Conclusions

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.

DAlangi_WMF changed the task status from Open to In Progress.Sep 28 2023, 4:21 PM

Tgr updated the task description. (Show Details)Sep 29 2023, 8:01 AM

Implementation

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.

Viability

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.

Google says

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.

Tgr mentioned this in T348388: Use central login wiki for login (SUL3).Oct 7 2023, 11:39 PM

Frostly subscribed.Jan 7 2024, 2:07 AM

Tgr mentioned this in T359947: Test cross-domain authentication with Federated Credentials Management API.Mar 12 2024, 2:56 PM

Tgr added a subtask: T359947: Test cross-domain authentication with Federated Credentials Management API.

AllUsernamesArePicked subscribed.Mar 12 2024, 3:04 PM

Bugreporter mentioned this in T345589: Investigate the First-Party Sets / Related Website Sets browser API.Wed, Apr 17, 12:56 AM