Publicado em: 8 de setembro de 2025
Líderes de vários setores entendem a importância de proteger a privacidade e oferecer uma ótima experiência do usuário. O Seznam tem o compromisso de oferecer uma experiência do usuário e privacidade sem concessões e integrou com sucesso o Gerenciamento de credenciais federadas (FedCM, na sigla em inglês).
Empresas que se beneficiam da FedCM
Organizações de vários domínios integram a FedCM às soluções delas. Como a FedCM foi projetada para o gerenciamento de identidades federadas, os provedores de identidade (IdPs) são os principais beneficiários. Eles usam isso para oferecer uma experiência de login melhor. Os provedores de serviços de e-commerce e de pagamento, muitos dos quais também atuam como provedores de identidade, também identificam oportunidades de melhorar a experiência do usuário com a FedCM.
Seznam
A Seznam é uma empresa de tecnologia e provedora de identidade europeia que atinge 90% da população da República Tcheca. Ele serve como um hub social, de conhecimento e de conteúdo. A Seznam adotou a FedCM para permitir que os clientes de lojas on-line que operam nas plataformas dos parceiros façam login usando a conta da Seznam.
Com a FedCM, o Seznam alcançou um aumento significativo nas taxas de login dos usuários em redes de parceiros, uma experiência do usuário aprimorada e um fluxo de identidade consistente, independentemente da disponibilidade de cookies de terceiros.
Motivação
O Seznam optou por implementar o FedCM devido a várias vantagens reconhecidas:
- O FedCM foi projetado pensando no usuário final, a ele o controle sobre as informações fornecidas ao IdP. Isso está alinhado à visão da Seznam de um ambiente seguro e privado para os usuários.
- A FedCM é um recurso integrado do navegador e é compatível com a experiência de login atual do Seznam, que usa o padrão OAuth 2.0.
- A FedCM é uma abordagem de federação de identidade com foco na privacidade. Por exemplo, a visita do usuário ao relying party (RP) só é compartilhada com o IdP se o usuário fizer login. Isso está alinhado à visão da Seznam sobre negócios sustentáveis.
Detalhes da implementação
A Seznam implementou a FedCM como uma camada sobre a solução OAuth atual. Nessa arquitetura, o fluxo da FedCM transmite com segurança um código de autorização do OAuth do IdP para os RPs.
Esforço de implementação
A Seznam achou a implementação da FedCM simples e alinhada à abordagem atual. A pesquisa e a implementação da API duraram um mês e exigiram dois desenvolvedores. Levou menos de dois meses para levar a FedCM à produção. O processo foi iterativo, com muito tempo dedicado ao estudo da API.
Desafios
Como um dos primeiros a adotar a API, o Seznam identificou vários desafios e enviou feedback valioso que ajudou a amadurecer a API.
Suporte para vários provedores de identidade
A Seznam se interessou pelo suporte da FedCM a vários provedores de identidade. Com esse recurso, o objetivo era permitir que os usuários escolhessem entre o Seznam ou as Contas do Google em RPs de parceiros. No entanto, quando o Seznam abordou a implementação da FedCM, o recurso estava em um estágio inicial de implementação, e os desenvolvedores precisavam se inscrever em um teste de origem e usar um token para ativar o recurso para os usuários. Por isso, o Seznam preferiu esperar que o recurso fosse lançado no Chrome Stable.
O recurso está disponível a partir do Chrome 136, e os desenvolvedores podem configurar o suporte para vários provedores de identidade. Por exemplo, para oferecer suporte aos provedores de identidade do Seznam e do Google, o IdP pode incluir os dois provedores em uma única chamada get(), e o RP pode fazer isso de forma independente:
// 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',
},
],
},
});
A Seznam indica que esse recurso fará parte da solução dela. Além disso, a equipe da FedCM está implementando suporte para vários SDKs, com suporte para várias chamadas get().
DNS particular
O Seznam enfrentou um desafio relacionado à configuração de rede durante a fase de testes. O servidor IdP de teste estava em uma rede particular, acessível apenas por DNS particular. Essa configuração é comum para testes internos e ambientes de desenvolvimento antes da exposição pública.
No entanto, essa configuração leva a um desafio: como um arquivo well-known precisa ser disponibilizado em um eTLD+1, e um domínio de desenvolvimento particular não está registrado na lista de sufixos públicos, o navegador não envia solicitações para buscar o arquivo well-known hospedado no domínio de desenvolvimento:
login.idp.example: exemplo de domínio de produção.idp.example/.well-known/web-identity: exemplo de arquivowell-knownem produção.login.dev.idp.example: exemplo de domínio de desenvolvimento.login.dev.idp.example/.well-known/web-identity: exemplo de arquivowell-knownno ambiente de desenvolvimento.
Quando a implementação da FedCM é hospedada em um domínio particular, as solicitações do navegador para o arquivo well-known resultam neste erro:
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
Para resolver esse erro, ative a flag #fedcm-without-well-known-enforcement do Chrome. Quando essa flag está ativada, o navegador pula a busca do arquivo well-known para fins de teste. Aprenda a ativar flags de teste no Chrome.
Divulgação de informações personalizadas
O Seznam também queria incluir mais informações junto com o design inicial da interface do FedCM. A caixa de diálogo padrão da FedCM mostra uma mensagem fixa ao usuário, informando que dados específicos (normalmente a imagem do perfil, o nome e o endereço de e-mail do usuário) são compartilhados com o RP.
A equipe do FedCM incorporou o feedback e estendeu a API para permitir a personalização da declaração apresentada ao usuário. Por exemplo, com o recurso Continuar em, o IdP pode redirecionar o usuário para uma página personalizada e solicitar mais informações ou permissões. Os recursos Parâmetros personalizados e Campos, com suporte a partir do Chrome 132, permitem mais personalização.
Validação da origem do objeto de confiança
O servidor IdP precisa validar o cabeçalho HTTP Origin em uma solicitação FedCM recebida para garantir que ela corresponda à origem que o RP pré-registrou com o IdP. Isso garante que a solicitação de declaração de ID da API FedCM venha de um RP autorizado, e não de um invasor usando client_id.
O Seznam tem um caso extremo: quando os RPs parceiros se registram no Seznam, ele não solicita os dados de origem do RP. Isso significa que não é possível verificar a origem do RP.
A integração da FedCM do Seznam se baseia em uma solução OAuth atual. Ele seguiu o caminho alternativo de validar client_id e client_secret do RP para garantir que a solução permanecesse segura sem verificar a origem.
Domínio do provedor de identidade voltado ao usuário
A infraestrutura de autenticação de usuários do Seznam opera principalmente no domínio szn.cz, onde os endpoints de IdP necessários para a FedCM são hospedados. No entanto, a principal identidade corporativa e o domínio em que os usuários reconhecem e confiam nos serviços são seznam.cz.
A caixa de diálogo da FedCM mostra o domínio de origem real dos endpoints do IdP: szn.cz. Os usuários familiarizados com a marca seznam.cz podem ficar confusos e hesitar ao receber uma solicitação para fazer login com o domínio szn.cz, que é menos conhecido, durante o processo de login.
A partir do Chrome 141, a FedCM não permite mostrar um domínio diferente daquele que hospeda a implementação do IdP. Essa restrição é uma escolha de design deliberada para garantir a transparência do usuário. No entanto, a equipe da FedCM reconhece os desafios que essa limitação pode criar e está discutindo possíveis ajustes.
Impacto
Com a API FedCM, o Seznam agora pode oferecer fluxos de autorização com um único toque para usuários parceiros. Ele destacou os benefícios da UX da FedCM em comparação com outros métodos de autenticação.
Embora o Seznam tenha notado um aumento significativo no engajamento dos usuários em sites que fizeram a transição para o login do FedCM, ele não realizou uma análise abrangente para isolar o impacto direto preciso de outros fatores. Antes da integração da FedCM, a implementação permitia finalizações de compra como convidado usando e-mails criptografados com hash consentidos para identificação do usuário. O desafio de realizar essa análise era estimar se uma conversão do usuário poderia ser atribuída ao FedCM ou se o usuário teria concluído uma compra usando o pagamento como visitante. A hipótese da Seznam sugere que a facilidade de uso aprimorada da FedCM pode ter contribuído para essa taxa de conversão mais alta.
Conclusão
O Seznam implementou a FedCM com sucesso, oferecendo um fluxo de autorização alternativo junto com a solução OAuth atual. Embora o Seznam tenha enfrentado alguns desafios relacionados ao suporte a provedores de identidade, configurações de DNS particulares, personalização do texto de divulgação, validação de origem da parte confiante e exibição de domínio para o usuário, a API amadureceu desde a implementação. A equipe da FedCM incorporou o feedback da Seznam e de outros usuários pioneiros, permitindo ferramentas melhores para enfrentar esses desafios. Como próxima etapa, a Seznam planeja implementar o suporte da FedCM a vários provedores de identidade.