Líderes de vários setores entendem a importância de proteger a privacidade e oferecer uma ótima experiência para todos os usuários. A Seznam, dedicada a oferecer privacidade e experiência do usuário sem concessões, integrou com sucesso o Gerenciador de credenciais federadas (FedCM, na sigla em inglês).
Perfis segmentados: empresas que se beneficiam da FedCM
Organizações de vários domínios integraram a FedCM às soluções. Devido ao design da FedCM para gerenciamento de identidade federada, os provedores de identidade (IdPs) são os principais beneficiários, usando-a para oferecer uma experiência de login aprimorada. Os provedores de serviços de e-commerce e de pagamento, muitos dos quais também atuam como provedores de identidade, identificaram oportunidades de melhorar a experiência do usuário com a implementação da 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 notável nas taxas de login dos usuários nas redes dos parceiros, uma experiência do usuário aprimorada e um fluxo de identidade consistente, independentemente da disponibilidade de cookies de terceiros.
Motivação
A escolha da Seznam de implementar o FedCM foi motivada por várias vantagens que ela reconheceu:
- 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 compatível com a experiência de login atual do Seznam, que usa o padrão OAuth 2.0.
- A FedCM foi projetada para ser uma abordagem de federação de identidade com foco na privacidade. Por exemplo, o fato de o usuário ter visitado a parte confiável (RP) só é compartilhado com o IdP se o usuário escolher fazer 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 é usado para transmitir com segurança um código de autorização do OAuth do IdP para os RPs.
Esforço de implementação
A Seznam destacou que a implementação da FedCM foi simples, alinhada à abordagem atual. A pesquisa e a implementação da API duraram um mês e exigiram o esforço de dois desenvolvedores. Eles levaram menos de dois meses para colocar o FedCM em produção. O processo foi iterativo, com muito tempo dedicado ao estudo cuidadoso 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 contas do Seznam ou do Google nas RPs dos parceiros. No entanto, quando o Seznam abordou pela primeira vez 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 também pode fazer isso de forma independente:
// 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',
},
],
},
});
A Seznam indicou 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
A Seznam enfrentou um desafio relacionado à configuração de rede durante a fase de testes. O servidor IdP de teste deles estava em uma rede particular, acessível apenas por DNS particular. Essa configuração é comum para ambientes internos de teste e desenvolvimento antes que os serviços sejam expostos publicamente.
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: exemplo de domínio de produção.idp.example/.well-known/web-identity: exemplo de arquivo conhecido em produção.login.dev.idp.example: exemplo de domínio de desenvolvimento.login.dev.idp.example/.well-known/web-identity: exemplo de arquivo conhecido 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 pula a busca do arquivo well-known para fins de teste. Saiba
como ativar flags de teste no Chrome.
Divulgação de informações personalizadas
O Seznam também compartilhou que queria incluir mais informações no 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) estão sendo compartilhados com o RP.
A equipe do FedCM incorporou o 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 e solicitar mais informações ou permissões. Os recursos de parâmetros personalizados e campos, compatíveis com o Chrome 132, permitem mais personalização.
Validação da origem do objeto de confiança
O servidor do IdP precisa validar o cabeçalho HTTP Origin em uma solicitação de FedCM recebida para garantir que a
solicitação corresponda à origem que o RP pré-registrou com o IdP. Isso garante que a
solicitação de declaração de ID
da FedCM venha de um RP autorizado, e não de um invasor usando client_id.
O Seznam tem uma situação de caso extremo: quando os RPs parceiros se registram no Seznam, eles não solicitam 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 é baseada em uma solução OAuth atual. Eles seguiram o caminho alternativo de validar o client_id e o client_secret do RP para garantir que a solução permanecesse segura sem a necessidade de 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, que é 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 do FedCM mostra o domínio de origem real dos endpoints do IdP. Neste caso, szn.cz.
Os usuários familiarizados com a marca seznam.cz podem ficar confusos e hesitar ao serem solicitados a 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 a exibição de 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 ao 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 aos usuários dos parceiros. Eles destacaram 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 consentidos para identificação do usuário. O desafio de realizar essa análise foi 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 do Seznam sugere que a facilidade de uso aprimorada oferecida pelo 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 os desenvolvedores da Seznam tenham enfrentado alguns desafios relacionados ao suporte do provedor 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 voltada ao 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 resolver esses desafios. Como próxima etapa, a Seznam planeja implementar o suporte da FedCM para vários provedores de identidade.