Publicado em: 8 de setembro de 2025
Líderes do setor em vários setores entendem a importância de proteger a privacidade e oferecer uma ótima experiência do usuário. A Seznam se dedica a oferecer uma experiência do usuário e privacidade sem concessões e integrou com sucesso o Gerenciador de credenciais federadas (FedCM).
Empresas que se beneficiam da FedCM
Organizações de diversos domínios integram a FedCM às soluções. Como a FedCM foi projetada para o gerenciamento de identidade federada, os provedores de identidade (IdPs) são os principais beneficiários. Eles a usam para oferecer uma experiência de login aprimorada. Os provedores de serviços de e-commerce e de pagamentos, 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 provedor de identidade europeu que atinge 90% da população tcheca. Ela 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, a Seznam alcançou um aumento significativo nas taxas de login do usuário 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
A Seznam escolheu implementar a FedCM devido a várias vantagens reconhecidas:
- A FedCM foi projetada pensando no usuário final, a ele o controle das informações fornecidas ao IdP. Isso está alinhado à visão da Seznam de um ambiente seguro e particular para os usuários.
- A FedCM é um recurso integrado do navegador e é compatível com a experiência de login atual da Seznam, que usa o padrão OAuth 2.0.
- A FedCM é uma abordagem centrada na privacidade para a federação de identidade. Por exemplo, a visita do usuário à parte confiável (RP) é compartilhada apenas 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 OAuth do IdP para as RPs.
Esforço de implementação
A Seznam considerou 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. Foram necessários menos de dois meses para levar a FedCM à produção. O processo foi iterativo, com um tempo substancial dedicado ao estudo da API.
Desafios
Como uma das primeiras a adotar a FedCM, a Seznam identificou vários desafios e forneceu feedback valioso que ajudou a amadurecer a API.
Suporte a vários provedores de identidade
A Seznam estava interessada no suporte da FedCM a vários provedores de identidade. Com esse recurso, a empresa pretendia permitir que os usuários escolhessem entre contas da Seznam ou do Google em RPs de parceiros. No entanto, quando a 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, a Seznam optou por 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 a vários provedores de identidade. Por exemplo, para oferecer suporte aos provedores de identidade da Seznam e do Google, o IdP pode incluir os dois provedores em uma única chamada get(), e a 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. Além disso, a equipe da FedCM está implementando suporte a vários SDKs, com suporte a várias chamadas get().
DNS particular
A Seznam encontrou um desafio relacionado à configuração de rede durante a fase de testes. O servidor de 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 veiculado de 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: domínio de produção de exemplo.idp.example/.well-known/web-identity: arquivowell-knownde exemplo em produção.login.dev.idp.example: domínio de desenvolvimento de exemplo.login.dev.idp.example/.well-known/web-identity: arquivowell-knownde exemplo no 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 ignora a busca do arquivo well-known para fins de teste. Aprenda a ativar flags de teste no Chrome.
Divulgação de informações personalizadas
A Seznam também queria incluir mais informações no design inicial da interface da 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 a RP.
A equipe da FedCM incorporou feedback e estendeu a API para permitir a personalização da divulgação apresentada ao usuário. Por exemplo, com o recurso "Continuar em", o IdP pode redirecionar o usuário para uma página personalizada para solicitar mais informações ou permissões. Os parâmetros personalizados e os recursos de campos, com suporte a partir do Chrome 132, permitem mais personalização.
Validação de origem da parte confiável
O servidor do IdP precisa validar o cabeçalho HTTP Origin em uma solicitação da FedCM recebida para garantir que a solicitação corresponda à origem que a RP pré-registrou com o IdP. Isso garante que a solicitação de declaração de ID da FedCM venha de uma RP autorizada e não de um invasor que usa client_id.
A Seznam tem um caso extremo: quando as RPs parceiras se registram na Seznam, ela não solicita os dados de origem da RP. Isso significa que a origem da RP não pode ser verificada.
A integração da FedCM da Seznam é baseada em uma solução OAuth atual. Ela seguiu o caminho alternativo de validar o client_id e o client_secret da RP para garantir que a solução permanecesse segura sem verificar a origem.
Domínio voltado para o usuário do provedor de identidade
A infraestrutura de autenticação do usuário da 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 amplamente 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 familiar, 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 destinada a 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, a Seznam agora pode fornecer fluxos de autorização de toque único para usuários parceiros. Ela destacou os benefícios da experiência do usuário da FedCM em comparação com outros métodos de autenticação.
Embora a Seznam tenha notado um aumento significativo no engajamento do usuário em sites que fizeram a transição para o login da FedCM, ela 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 check-outs de visitantes usando e-mails com hash consentidos para identificação do usuário. O desafio de realizar essa análise era estimar se uma conversão de usuário poderia ser atribuída à FedCM ou se o usuário teria concluído uma compra usando o check-out de 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
A Seznam implementou a FedCM com sucesso, fornecendo um fluxo de autorização alternativo junto com a solução OAuth atual. Embora a Seznam tenha enfrentado alguns desafios relacionados ao suporte do provedor de identidade, configurações de DNS particular, personalização do texto de divulgação, validação de origem da parte confiável e exibição de domínio voltado para o usuário, a API amadureceu desde a implementação. A equipe da FedCM incorporou feedback da Seznam e de outros usuários iniciais, permitindo melhores ferramentas para enfrentar esses desafios. Como próxima etapa, a Seznam planeja implementar o suporte da FedCM a vários provedores de identidade.