Seamless and private user authentication with FedCM: Seznam's implementation

Industry leaders across multiple sectors understand how important it is to protect privacy while providing a great experience for all their users. Seznam, dedicated to delivering uncompromised user experience and privacy, has successfully integrated Federated Credential Management (FedCM).

Target profiles: Companies benefiting from FedCM

Organizations across diverse domains have integrated FedCM with their solutions. Given FedCM's design for federated identity management, identity providers (IdPs) are its primary beneficiaries, using it to offer an improved login experience. Ecommerce service providers and payment providers, many of whom also act as identity providers, have also identified opportunities to improve user experience through FedCM's implementation.

Seznam

Seznam is a European technology company and identity provider reaching 90% of the Czech population. It serves as a social, knowledge, and content hub. Seznam adopted FedCM to allow customers of online stores operating on their partners' platforms to sign in using their Seznam account.

The FedCM dialog is displayed on eshop.starkl.com, suggesting the user to sign in with their Seznam account.
FedCM dialog suggesting the user to sign in with Seznam on their partner's site.

With FedCM, Seznam achieved a noticeable increase in user sign-in rates on their partners' networks, an improved user experience, and a consistent identity flow regardless of third-party cookie availability.

Motivation

Seznam's choice to implement FedCM was driven by several advantages they recognized:

  • FedCM is designed with the end user in mind, giving the user control over the information provided to the IdP. This aligns with Seznam's vision of a secure and private environment for their users.
  • FedCM is a built-in browser feature that is compatible with Seznam's existing login experience, which uses the OAuth 2.0 standard.
  • FedCM is designed to be a privacy-centric approach to identity federation. For example, the fact that the user visited the relying party (RP) is only shared with the IdP if the user chooses to sign in. This aligns with Seznam's view on sustainable business.

Implementation details

Seznam implemented FedCM as a layer on top of their existing OAuth solution. In this architecture, the FedCM flow is utilized to securely transmit an OAuth authorization code from the IdP to the RPs.

A sequence diagram showing the FedCM flow where the FedCM token is exchanged for OAuth authorization code on the IdP side
FedCM flow integrated with OAuth. See the diagram's code.

Implementation effort

Seznam highlighted that the implementation of FedCM was straightforward, aligning with their existing approach. Their research and implementation of the API spanned a month and required the effort of two developers. It took them less than two months to bring FedCM to production. The process was iterative, with substantial time devoted to carefully studying the API.

Challenges

As an early adopter, Seznam identified several challenges and provided valuable feedback that helped mature the API.

Support for multiple identity providers

Seznam was interested in FedCM's support for multiple identity providers. With this feature, they aimed to allow users to choose between Seznam or Google accounts on their partners' RPs. However, when Seznam first approached their FedCM implementation, the feature was in an early stage of implementation, and developers were required to sign up for an origin trial and use a token to enable the feature for their users. For this reason, Seznam chose to wait for the feature to be shipped in Chrome Stable.

The feature is available from Chrome 136, and developers can configure support for multiple identity providers. For example, to support both Seznam and Google identity providers, the IdP can include the two providers in a single get() call, and the RP can also do so independently:

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam's config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Also allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam has indicated this feature will be part of their solution. Additionally, the FedCM team is implementing support for multiple SDKs, with support for multiple get() calls.

Private DNS

Seznam encountered a challenge related to their network configuration during the testing phase. Their test IdP server resided within a private network, accessible only through private DNS. This setup is common for internal testing and development environments before services are exposed publicly.

However, this setup leads to a challenge: because a well-known file must be served from an eTLD+1, and a private development domain is not registered in the Public Suffix List, the browser won't send requests to fetch the well-known file hosted on the development domain:

  • login.idp.example: example production domain.
  • idp.example/.well-known/web-identity: example well-known file in production.
  • login.dev.idp.example: example development domain.
  • login.dev.idp.example/.well-known/web-identity: example well-known file in development environment.

When the FedCM implementation is hosted on a private domain, browser requests to the well-known file result in this error:

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

This error can be solved by enabling the Chrome #fedcm-without-well-known-enforcement flag. When this flag is enabled, the browser skips fetching the well-known file for testing purposes. Learn how to enable testing flags in Chrome.

Custom information disclosure

Seznam also shared that they wanted to include additional information alongside the initial design of the FedCM UI. The standard FedCM dialog displays a fixed message to the user, stating that specific data—typically the user's profile image, name, and email address—is being shared with the RP.

The FedCM team incorporated feedback and extended the API to allow for customization of the disclosure presented to the user. For example, with the Continue on feature, the IdP can redirect the user to a custom page to request additional information or permissions. Custom parameters and Fields features, supported from Chrome 132, allow for further customization.

An IdP page showing that to continue the FedCM sign-up, the user must grant additional permissions, in this case, viewing and downloading Drive files and calendar events.
The user can review and grant additional permissions passed by the RP to the ID assertion endpoint endpoint with the Parameters API.

Relying Party origin validation

The IdP server must validate the Origin HTTP header on an incoming FedCM request to ensure the request matches the origin the RP pre-registered with the IdP. This ensures that the FedCM ID assertion request is coming from an authorized RP, and not from an attacker using client_id.

Seznam has a corner case situation: when their partner RPs register with Seznam, they don't request the RP's origin data. This means that the RP's origin cannot be verified.

Seznam's FedCM integration is built on top of an existing OAuth solution. They took the alternative path of validating both RP's client_id and client_secret to ensure that the solution remained secure without the need to check the origin.

Identity provider user-facing domain

Seznam's user authentication infrastructure operates primarily on the szn.cz domain, which is where the necessary IdP endpoints for FedCM are hosted. However, their main corporate identity and the domain under which users widely recognize and trust their services is seznam.cz.

The FedCM dialog displays the actual origin domain of the IdP endpoints – in this case, szn.cz. Users familiar with the seznam.cz brand might experience confusion, and hesitate when prompted to sign in with the less familiar szn.cz domain during the login process.

As of Chrome 141, FedCM does not allow the display of a domain different from the one hosting the IdP implementation. This restriction is a deliberate design choice intended to ensure transparency for the user. However, the FedCM team recognizes the challenges this limitation may create and is discussing potential adjustments.

Impact

With the FedCM API, Seznam can now provide single tap authorization flows to their partners' users. They highlighted the benefits provided by FedCM's UX compared to other authentication methods.

While Seznam noted a significant increase in user engagement on websites that transitioned to FedCM login, they did not perform a comprehensive analysis to isolate the precise direct impact from other factors. Prior to FedCM integration, the implementation allowed guest checkouts using consented hashed emails for user identification. The challenge to perform such an analysis was to estimate whether a user conversion could be attributed to FedCM, or if the user would have completed a purchase using guest checkout. Seznam's hypothesis suggests that the improved ease of use offered by FedCM might have contributed to this higher conversion rate.

Conclusion

Seznam successfully implemented FedCM, providing an alternative authorization flow alongside their existing OAuth solution. While Seznam developers faced some challenges related to identity provider support, private DNS setups, customization of the disclosure text, relying party origin validation, and user-facing domain display, the API has matured since their implementation. The FedCM team has incorporated feedback from Seznam and other early adopters, allowing for better tools to solve these challenges. As a next step, Seznam plans to implement FedCM's support for multiple identity providers.