Linkagem de Conta Bidirecional Verificada em uma Plataforma de Identidade de Nove Marcas

Essa flexibilidade criou um problema de identidade. Quando um cliente entrava com uma nova identidade Apple ou Google cujo e-mail já pertencia a uma conta existente, a plataforma precisava decidir o que fazer. Vincular os dois automaticamente apenas em um match de e-mail seria inseguro: um endereço de e-mail correspondente sugere um relacionamento, mas isso não prova que a pessoa que faz login realmente controla essa caixa de entrada. A plataforma precisava de uma forma de conectar identidades compatíveis da Apple e do Google a uma conta compartilhada sem nunca conceder acesso a um e-mail de correspondência sozinha, e fazer isso de forma consistente entre as nove marcas, incluindo os casos complicados: endereços privados de retransmissão da Apple, contas com senha, logins arriscados e interrupções de provedores.

As limitações eram concretas. O link precisava ser bidirecional e independente da ordem: o Google primeiro, depois a Apple, ou a Apple primeiro e depois o Google, precisava alcançar a mesma conta compartilhada. O Esconder Meu E-mail da Apple teve que ser tratado separadamente, porque um endereço de retransmissão privada que não corresponde ao e-mail real da conta do cliente não deve se vincular silenciosamente a essa conta. A verificação teve que reutilizar o mesmo mecanismo de desafio de código já confiável para autenticação de alto risco, então vincular herdou controles comprovados em vez de inventar novos. O risco precisava modular o atrito: os registros de baixo risco deveriam permanecer sem atrito, enquanto o risco médio, alto e indeterminado exigia um OTP. Falhas repetidas precisavam ser contidas por meio de uma política de bloqueio que se aplicava ao nível da conta, em todas as marcas, não por marca. E falhas de provedores precisavam ser seguras, nunca deixando um cliente com uma conta parcial ou duplicada.

O mesmo caminho verificado cobria ambas as direções de ligação. Se um cliente criasse uma conta no Google e depois escolhesse Continuar com a Apple usando o mesmo e-mail compartilhado, o sistema detectava a conta existente, enviava um código para seu e-mail e vinculava a Apple após a verificação bem-sucedida. O contrário, o Compartilhe Meu E-mail da Apple primeiro e o Google depois, resolveu para a mesma conta compartilhada pelo mesmo desafio. Após o link, o cliente podia fazer login com a Apple, com o Google ou com e-mail e senha, onde quer que uma tenha sido configurada, e acabar na mesma conta.

O Esconder Meu E-mail da Apple seguiu um caminho propositalmente separado. Quando o endereço privado de retransmissão não correspondia ao e-mail pessoal não divulgado do cliente, as identidades não eram elegíveis para o mesmo e-mail. Em vez de vincular o relé a uma conta não relacionada, a plataforma mostrou uma explicação de acesso limitado e criou uma conta de e-mail separada. Além do primeiro link, a mesma conta tinha seu próprio ciclo de vida: um cliente podia definir uma senha em uma conta social, alterar o e-mail principal (que desvinculava o provedor social anterior e exigia reverificação), e cada login retornado ainda passava por avaliação de risco antes da sessão ser emitida.

A partir daí, o fluxo se ramificou em resultados claramente limitados. Uma correspondência de e-mail elegível emitia um código de vinculação ao e-mail da conta existente; Após a verificação bem-sucedida, o provedor era vinculado; em caso de falha, a tentativa era rejeitada e registrada. Um e-mail de retransmissão da Apple que não correspondia foi direcionado para uma explicação de acesso limitado e uma conta de e-mail separada. Uma vez resolvido para uma conta compartilhada entre marcas, o status da conta era verificado: uma conta bloqueada era mostrada como bloqueada, uma conta ativa era classificada em uma categoria de risco. Baixo risco emitiu uma sessão autenticada diretamente; risco médio, alto e indeterminado enviou um OTP de autenticação, e repetidos desafios falhados, até um limite fixo, bloquearam a conta compartilhada entre as nove marcas. A própria conta expôs mudanças de configuração de senha e e-mail, onde mudar o e-mail principal desvinculou o provedor social anterior e exigiu uma nova verificação do provedor. Falhas no serviço do provedor não criaram estado parcial: retornaram um erro seguro e tentaram novamente que foi roteado de volta para o mesmo orquestrador, então uma falha na chamada Apple ou Google nunca produziu uma conta meio vinculada ou duplicada. O limite de vinculação combinava três verificações: uma resposta validada do provedor, uma correspondência compatível com o mesmo e-mail e um desafio de código de e-mail bem-sucedido, e as submissões de código falhadas passavam pela mesma política de controle de desafio e bloqueio que os OTPs de risco.