Three new features shipping in Chrome 120

263 views

Skip to first unread message

Eiji Kitamura

unread,

Dec 5, 2023, 12:40:45 AM12/5/23

to fedcm-develop...@googlegroups.com

We have three exciting new features shipped in Chrome 120 and one announcement for Chrome 121.

The Login Status API is a mechanism where a website, especially an IdP, informs the browser its user's login status. With this API, the browser can reduce unnecessary requests to the IdP and mitigate potential timing attacks.

The Login Status API is a requirement for FedCM. If you have an existing implementation of FedCM, make sure the Login Status API is implemented, otherwise the FedCM dialog may not show up, even if a user is signed in to the IdP.

Error API

When Chrome sends a request to the ID assertion endpoint (for example, when a user clicks the Continue as button on the FedCM UI or auto-reauthentication is triggered), the IdP may not be able to issue a token for legitimate reasons. For example, if the client is unauthorized, the server is temporarily unavailable, and so on. Currently, Chrome fails the request silently in case of such errors and only notifies the RP by rejecting the promise.

With the Error API, Chrome notifies the user by showing a native UI with the error information provided by the IdP.

Auto-Selected Flag API

mediation:optional is the default user mediation behavior in the Credential Management API and it triggers automatic reauthentication when possible. However, auto-reauthentication may be unavailable due to a combination of factors and the user may be prompted to sign in with explicit user mediation, which is a flow with different properties.

From an API caller's perspective, when they receive an ID token, they don't have visibility over whether it was an outcome of an auto-reauthentication flow. That makes it hard for them to evaluate the API performance and improve UX accordingly.
From the IdP's perspective, they are equally unable to tell whether an auto reauthentication occurred or not for performance evaluation. In addition, whether an explicit user mediation was involved could help them support more security related features. For example, some users may prefer a higher security tier which requires explicit user mediation in authentication. If an IdP receives a token request without such mediation, they could handle the request differently. For example, return an error code such that the RP can call the FedCM API again with mediation: required.

This is why providing visibility of the auto-reauthentication flow would be beneficial to developers.

With the Auto-selected Flag API, Chrome shares whether an explicit user permission was acquired by tapping on the Continue as button with both the IdP and RP, whenever auto reauthentication occurred or an explicit mediation occurred. Sharing only happens after user permission is granted for IdP/RP communication.

See more details about these three new features in our announcement blog post.

The relaxed condition for triggering FedCM auto-reauthentication

The auto-reauthentication feature in FedCM is only triggered when the user is returning. This means the user needs to sign in to the RP using FedCM once on every browser instance, before auto-reauthentication can be triggered. This condition was initially introduced to mitigate the risk of trackers pretending to be an identity provider (IdP) and tricking the browser into auto-reauthenticating a user without their knowledge or consent. However, this design cannot guarantee the privacy benefit if the tracker has access to third-party cookies on the RP context. FedCM provides only a subset of the capabilities possible via third-party cookies, so if the tracker already has access to third-party cookies on the RP context, access to FedCM presents no additional privacy risk.

Since there are legitimate uses of third-party cookies and relaxing the condition would improve the UX, this behavior is changing from Chrome 121. We have decided to relax the restriction of the condition to treat a user as returning: if third-party cookies are available to the IdP on the RP context, Chrome will trust the IdP’s claim about user’s account status specified via the `approved_clients` list and trigger auto re-authentication if applicable. Third-party cookies can be available through: user settings, enterprise policies, heuristics (Safari, Firefox, Chrome in progress) and other web platform APIs (such as Storage Access API). Note that when the IdP loses third party cookies access in the future, if a user has never explicitly granted permission on the FedCM UI (for example, clicking the “Continue as” button) before, they will still be treated as a new user.

There are no developer actions required. Please note that auto-reauthentication flow could be triggered more with this change if the IdP has third-party cookies access and claims that the user has created an account on the RP in the past.