Desfragmentar logins entre domínios

Eiji Kitamura

As arquiteturas de negócios modernas costumam abranger vários domínios distintos. As organizações mantêm ambientes dedicados para diferentes recursos, como brand.example para marketing, service-app.example para o produto principal e support-portal.example para atendimento ao cliente. O ideal é oferecer uma experiência unificada de login único à medida que os usuários navegam por essas propriedades. No entanto, as equipes de engenharia costumam integrar esses domínios usando técnicas ad hoc que causam fragmentação. Isso interrompe o gerenciamento de credenciais integrado do navegador, quebrando os fluxos de preenchimento automático do gerenciador de senhas e paralisando a adoção de chaves de acesso.

Se a mesma conta abranger vários domínios, o usuário precisará reconhecer que os domínios pertencem à mesma organização e fornecer as mesmas credenciais ao fazer login. No pior caso, o usuário cria uma conta duplicada ou entrega a senha a um site de phishing.

Saiba como usar padrões e soluções arquitetônicas (como metadados, iframes entre origens, federação de identidade e consolidação de subdomínios) para resolver a fragmentação de identidade entre domínios e oferecer uma jornada do usuário integrada.

Soluções alternativas comuns

As organizações usam várias técnicas estabelecidas para manter uma jornada entre domínios. Embora esses métodos sejam comuns, eles enfrentam obstáculos estruturais à medida que os navegadores aplicam limites de privacidade e padrões de segurança mais rigorosos.

Solicitações de busca do CORS

Quando os domínios operam de forma independente, os front-ends costumam usar solicitações entre origens fetch() direcionadas a uma API de autenticação centralizada, que pode ser permitida com segurança usando o compartilhamento de recursos entre origens (CORS). Como os navegadores costumam bloquear ou restringir cookies de vários sites, os desenvolvedores podem projetar explicitamente essas APIs para retornar tokens de autenticação, como JSON Web Tokens (JWTs) em payloads JSON, em vez de usar cabeçalhos Set-Cookie.

Compartilhamento de banco de dados de contas

Para unificar a identidade no back-end sem integrações complexas de front-end, você pode centralizar o armazenamento de dados do usuário. Embora vários domínios sejam autenticados no mesmo banco de dados, as experiências de login do front-end permanecem separadas. Isso obriga os usuários a lembrar quais domínios usaram a mesma credencial, o que leva a uma experiência ruim do usuário.

Problemas com logins separados

Embora as soluções técnicas alternativas possam alcançar a funcionalidade básica, elas não oferecem uma jornada integrada. Os fluxos de login separados introduzem pontos de atrito que comprometem a usabilidade e a segurança.

Fragmentação do gerenciador de senhas

O maior ponto de atrito é a interrupção dos gerenciadores de senhas. Os gerenciadores de senhas vinculam as credenciais armazenadas à origem específica em que estão registradas. Isso impede que o navegador ofereça preenchimento automático em diferentes domínios, mesmo quando pertencem à mesma organização.

Quando um usuário faz a transição de um domínio com credenciais salvas para um novo domínio na sua organização, o gerenciador de senhas não reconhece a relação e não aciona o comando de preenchimento automático. Isso cria atrito de entrada manual. Os usuários precisam pesquisar as credenciais, redefinir a senha ou criar uma conta duplicada.

Como o gerenciador de senhas não é confiável nessas propriedades, os usuários podem abandonar as ferramentas desses sites. Em vez disso, eles costumam criar senhas fracas e memoráveis para reutilizar em outros lugares, o que prejudica a segurança geral da sua organização.

Gateway de phishing

Essa interrupção funciona como um gateway de phishing. A recusa de um gerenciador de senhas em preencher automaticamente um domínio não reconhecido é um mecanismo de defesa principal. Ao exigir que os usuários insiram manualmente as credenciais em URLs diferentes, você treina involuntariamente os usuários para serem vítimas de ataques de phishing.

Roadblock de chaves de acesso

O atrito aumenta quando você usa chaves de acesso. A arquitetura de segurança principal do WebAuthn vincula criptograficamente as chaves de acesso estritamente a um ID de parte confiável (RP, na sigla em inglês) especificado.

Isso cria uma "armadilha de ID de RP". Uma chave de acesso registrada em brand.example não pode ser usada em service-app.example porque o navegador nega o acesso entre domínios. Para evitar que os usuários registrem chaves de acesso distintas para cada site, é necessário consolidar essas propriedades em um único ID de RP.

Abordagens recomendadas

Para estabelecer a continuidade da identidade, é necessário abandonar as integrações de login ad hoc e adotar padrões arquitetônicos reconhecidos:

• Usar arquivos de configuração de metadados: hospede arquivos de metadados, como Digital Asset Links e solicitações de origem relacionada, para estabelecer uma cadeia de confiança criptográfica. Isso permite o compartilhamento integrado de credenciais e chaves de acesso em diferentes domínios e apps para dispositivos móveis. Essa abordagem é uma correção silenciosa e de baixo custo para a fragmentação de identidade que não exige uma rearquitetura complexa da infraestrutura da Web atual.
• Usar iframes entre origens: incorpore uma origem de autenticação centralizada como um iframe em uma parte confiável para vincular credenciais salvas e chaves de acesso em diferentes sites. Essa abordagem usa a política de permissões e cookies particionados para permitir uma experiência de login integrada e contextual, mantendo limites de segurança rigorosos por meio de CSP e mensagens entre documentos.
• Seguir a federação de identidade padrão: Adote protocolos padrão do setor, como o OpenID Connect, para centralizar a autenticação em um domínio de provedor de identidade (IdP) dedicado. Isso formaliza a jornada de login por meio de redirecionamentos seguros, substituindo integrações frágeis por uma solução própria confiável e escalonável.
• Consolidar subdomínios: faça a transição para subdomínios em uma raiz comum. Isso permite o compartilhamento de sessões integrado por meio de cookies curinga e a continuidade da chave de acesso em todo o domínio registrável. Muitos gerenciadores de senhas podem reconhecer o domínio raiz compartilhado e sugerir automaticamente credenciais salvas em subdomínios relacionados.

Usar arquivos de configuração de metadados

Um dos principais desafios da identidade entre domínios é a fragmentação de credenciais salvas. Os gerenciadores de senhas tratam diferentes domínios e apps como entidades completamente isoladas, o que impede que eles preencham automaticamente as credenciais salvas em uma propriedade em outra.

Para resolver a fragmentação, você pode configurar o comportamento dos gerenciadores de senhas em vez de alterar a estrutura do site. Ao hospedar arquivos de configuração de metadados específicos, as organizações podem afirmar criptograficamente que domínios e aplicativos diferentes pertencem à mesma organização. Isso permite que sistemas operacionais, navegadores e gerenciadores de senhas reconheçam essa relação e vinculem automaticamente o contexto de identidade, compartilhando senhas e chaves de acesso nas suas propriedades. Essa abordagem também é necessária para compartilhar senhas e chaves de acesso baseadas na Web com aplicativos para dispositivos móveis, mesmo que seus domínios da Web estejam consolidados.

Use dois arquivos de configuração diferentes para garantir que você cubra diferentes plataformas e ecossistemas:

• Gerenciador de senhas do Google no Android e no Chrome: hospede um Digital Asset Links (DAL) arquivo JSON em /.well-known/assetlinks.json para estabelecer uma relação de confiança verificável entre os apps e sites associados de uma organização. Essa confiança permite links diretos em apps e o compartilhamento de credenciais integrado, em que as senhas salvas na Web são preenchidas automaticamente em sites associados (embora o compartilhamento de chaves de acesso em vários domínios da Web ainda exija solicitações de origem relacionada). Saiba mais no guia Compartilhamento de credenciais integrado.

• Senhas da Apple no iOS e no Safari: hospede um arquivo Apple App Site Association (AASA) em /.well-known/apple-app-site-association para estabelecer a cadeia de confiança criptográfica necessária para vincular os estados de senhas da Apple em apps iOS e no Safari. Para oferecer suporte a ecossistemas de terceiros, você pode declarar esses domínios associados de forma centralizada usando um repositório de crowdsourcing. Isso garante que ferramentas independentes (como o 1Password, que ingere explicitamente esse repositório) também reconheçam o contexto de identidade compartilhada. Para saber mais sobre a Apple App Site Association, leia Suporte a domínios associados.

Para ativar chaves de acesso em diferentes domínios da Web e resolver o roadblock de chaves de acesso, os desenvolvedores podem hospedar um arquivo de solicitações de origem relacionada (ROR) em /.well-known/webauthn. O ROR declara explicitamente os domínios autorizados que podem compartilhar com segurança o mesmo ID de RP de chave de acesso. Para saber mais sobre as solicitações de origem relacionada, leia Permitir a reutilização de chaves de acesso nos seus sites com solicitações de origem relacionada.

• Prós:
  • Correção em segundo plano para usuários finais:funciona totalmente em segundo plano, o que resolve automaticamente a fragmentação do preenchimento automático e estabelece a continuidade da chave de acesso no nível do SO ou do navegador sem mudanças visíveis na UX.
  • Implementação simples:essa é uma solução de baixo custo, que exige apenas a hospedagem de arquivos JSON estáticos. Não requer rearquitetura de back-end ou lógica complexa de troca de tokens.
  • Preserva a infraestrutura atual:você pode melhorar significativamente a jornada entre domínios sem mudar sua marca ou consolidar seus domínios.
• Contras:
  • Restrições de plataforma:as plataformas geralmente aplicam limites rigorosos ao ROR. Por exemplo, o Chrome restringe um único ID de RP a um máximo de cinco rótulos eTLD+1 associados. Para ilustrar, example.co.uk e example.de compartilham o mesmo rótulo eTLD+1 example. No entanto, example-rewards.com usa um rótulo example-rewards separado. Se você gerenciar um portfólio de domínios extenso ou variado, esses limites poderão ser insuficientes.
  • Aumento da latência operacional:a resolução de arquivos de metadados exige uma viagem de ida e volta extra na rede, o que adiciona latência quando o navegador processa a autenticação.

Usar iframes entre origens

Se você não puder usar a abordagem de arquivos de configuração de metadados devido aos limites de domínio do ROR, os elementos iframe entre origens vão oferecer um caminho robusto e com suporte a padrões para resolver os desafios de login entre domínios.

Ao incorporar uma origem de autenticação centralizada (por exemplo, auth.brand.example) como um iframe em uma parte confiável (por exemplo, brand.example), você pode interagir com campos de formulário comuns e APIs modernas. Para senhas, o gerenciador de credenciais do navegador associa ações de preenchimento automático à origem do iframe (auth.example). Isso permite que os usuários acessem as credenciais centralizadas de maneira integrada em diferentes sites.

Para chaves de acesso, a janela pai precisa conceder acesso ao iframe usando a estrutura da política de permissões, permitindo que o iframe invoque o WebAuthn para autenticar no ID de RP da própria origem. Em ambos os fluxos, a CSP (Política de Segurança de Conteúdo) é útil para proteger os usuários contra ataques como clickjacking e script em vários locais. Depois que a autenticação é bem-sucedida, a sessão é estabelecida com um cookie particionado e o token é transmitido com segurança de volta para a janela pai usando postMessage().

• Prós:
  • Credenciais centralizadas:evita a fragmentação de credenciais. Uma única origem centralizada gerencia senhas salvas e um ID de RP de chave de acesso unificado, permitindo que domínios distintos compartilhem essas credenciais sem precisar consolidar domínios.
  • Autenticação contextual:todo o fluxo de login, seja preenchendo automaticamente uma senha ou verificando com uma chave de acesso, acontece de maneira integrada no contexto da página pai, evitando redirecionamentos federados disruptivos.
  • Resiliência a proteções de rastreamento: essa abordagem funciona corretamente mesmo em proteções rigorosas de rastreamento entre sites usando cookies particionados.
• Contras:
  • Restrições de implementação:essa arquitetura exige engenharia especializada. Ela requer CSP estrita (frame-ancestors) para restringir a incorporação a domínios pai confiáveis e evitar clickjacking, configuração de políticas de permissões HTTP para ativar a API WebAuthn e mensagens seguras e validadas entre documentos (postMessage()) para mitigar ataques de falsificação de origem e CSRF. Saiba mais sobre as práticas recomendadas em Chaves de acesso em iframes.

Seguir a federação de identidade padrão

A adoção da federação de identidade padrão, como o OpenID Connect, é uma abordagem robusta e sustentável para manter o sistema de contas. Essa abordagem formaliza o fluxo de trabalho de autenticação, consolidando-o em um único domínio de provedor de identidade (IdP) dedicado, como auth.brand.example. Com um protocolo estabelecido, os aplicativos redirecionam os usuários para esse hub central para autenticação antes de receber uma transferência de token segura para concluir o login no domínio de destino. Embora seja frequentemente associada a logins de terceiros (como o recurso Fazer login com o Google), a federação padrão é totalmente válida e amplamente usada como uma solução própria para substituir soluções alternativas frágeis.

• Prós:
  • Linguagem de engenharia comum:os desenvolvedores não precisam aprender ou manter um protocolo específico e personalizado. Eles podem confiar no conhecimento estabelecido do setor e em bibliotecas abrangentes. Também há soluções empacotadas.
  • Confiabilidade testada:os protocolos padrão são comprovados, seguros e muito menos frágeis do que as implementações ad hoc.
  • Facilmente expansível:se a organização precisar federar com um novo serviço de terceiros ou integrar uma aquisição mais tarde, a infraestrutura de identidade já estará equipada para fornecer credenciais.
  • UX consistente:os usuários reconhecem a página do IdP centralizado como a fonte autorizada da marca, esclarecendo exatamente quando e onde as credenciais são necessárias.
• Contras:
  • Alto custo de integração:o desenvolvimento ou a migração para um IdP centralizado introduz um alto custo de integração e exige experiência especializada em segurança. As organizações precisam investir na refatoração segura de todos os aplicativos conectados para oferecer suporte a padrões seguros baseados em redirecionamento.
  • Redirecionamentos disruptivos:o fluxo de autenticação exige o redirecionamento dos usuários do site de origem para uma página de provedor de identidade centralizada, impedindo uma experiência de login integrada e contextual.

Consolidar subdomínios

Outra abordagem estrutural é unificar todos os domínios movendo propriedades digitais diferentes para um domínio raiz registrável comum (o eTLD+1). Isso envolve a transição de domínios separados, como brand.example e service-app.example para subdomínios, como www.brand.example e service.brand.example.

• Prós:
  • Gerenciamento de credenciais unificado:os gerenciadores de senhas podem reconhecer o domínio raiz e tratar todos os subdomínios como uma única entrada, eliminando comandos duplicados e entrada manual de senhas.
  • Continuidade da chave de acesso:os desenvolvedores podem definir nativamente um ID de RP de chave de acesso para o domínio registrável, estendendo instantaneamente o suporte à chave de acesso em todos os subdomínios associados. Nesse caso, um ID de RP de brand.example vai funcionar em www.brand.example e service.brand.example.
  • Compartilhamento de sessões sem esforço:a consolidação da estrutura de domínio permite o compartilhamento de uma única sessão usando cookies curinga (por exemplo, definindo um cookie para Domain=brand.example).
• Contras:
  • Restrições de marca e migração:essa abordagem pode impor limites de marca em potencial se a organização exigir domínios de nível superior distintos. A migração é complexa e exige um gerenciamento cuidadoso de redirecionamentos HTTP e uma correção extensa de configurações legadas entre origens.

Conclusão

Para alcançar a continuidade da identidade, é necessário fazer a transição de integrações de login ad hoc para padrões de autenticação estabelecidos. Ao avaliar as restrições de negócios em relação a essas práticas estabelecidas, como federação, consolidação de domínio, iframes ou metadados, você pode eliminar o atrito da UX e melhorar a autenticação em todo o ecossistema.

Para saber mais sobre tópicos relacionados, siga nosso blog e confira mais recursos no portal de identidade do Chrome.