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

Natalia Markoborodova

Published: September 8, 2025

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

Companies that benefit from FedCM

Organizations across diverse domains integrate FedCM with their solutions. Because FedCM is designed for federated identity management, identity providers (IdPs) are its primary beneficiaries. They use it to offer an improved sign-in experience. Ecommerce service providers and payment providers, many of whom also act as identity providers, also identify opportunities to improve user experience through FedCM.

Seznam

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

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

Motivation

Seznam chose to implement FedCM due to several recognized advantages:

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

Implementation details

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

FedCM flow, showing the FedCM token exchanged for an OAuth authorization code on the IdP side — FedCM flow integrated with OAuth. See the diagram code.

Implementation effort

Seznam found the FedCM implementation straightforward and aligned with its existing approach. Its research and API implementation spanned a month and required two developers. It took less than two months to bring FedCM to production. The process was iterative, with substantial time devoted to 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, it aimed to let users choose between Seznam or Google Accounts on partner RPs. However, when Seznam first approached its FedCM implementation, the feature was in an early implementation stage, and developers had to sign up for an origin trial and use a token to enable the feature for users. Because of this, Seznam chose to wait for the feature to be shipped in Chrome Stable.

The feature is available starting with 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 do so independently:

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

Seznam indicates this feature will be part of its 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 its network configuration during the testing phase. Its test IdP server resided within a private network, accessible only through private DNS. This setup is common for internal testing and development environments before public exposure.

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

You can resolve this error 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 wanted to include additional information alongside the initial FedCM UI design. 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 shared with the RP.

The FedCM team incorporated feedback and extended the API to enable 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 starting with Chrome 132, enable further customization.

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 comes from an authorized RP, and not from an attacker using client_id.

Seznam has a corner case: when its partner RPs register with Seznam, it does not request the RP's origin data. This means the RP's origin cannot be verified.

Seznam's FedCM integration builds on an existing OAuth solution. It took the alternative path of validating both RP's client_id and client_secret to ensure the solution remained secure without checking the origin.

Identity provider user-facing domain

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

The FedCM dialog displays the actual origin domain of the IdP endpoints: 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 sign-in process.

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

Impact

With the FedCM API, Seznam can now provide single tap authorization flows to partner users. It highlighted the benefits of FedCM's UX compared to other authentication methods.

While Seznam noted a significant increase in user engagement on websites that transitioned to FedCM sign-in, it did not perform a comprehensive analysis to isolate the precise direct impact from other factors. Before FedCM integration, the implementation allowed guest checkouts using consented hashed emails for user identification. The challenge in performing such an analysis was estimating 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 FedCM's improved ease of use might have contributed to this higher conversion rate.

Conclusion

Seznam successfully implemented FedCM, providing an alternative authorization flow alongside its existing OAuth solution. While Seznam 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 its implementation. The FedCM team has incorporated feedback from Seznam and other early adopters, enabling better tools to address these challenges. As a next step, Seznam plans to implement FedCM's support for multiple identity provid