Verificação de e-mail

A API Email Verification é uma proposta que permite que o navegador se comunique diretamente com o provedor de e-mail para verificar se o usuário é o proprietário do endereço de e-mail. Os usuários inserem o e-mail, enviam o formulário e o site verifica o token de verificação de e-mail assinado do navegador com o provedor sem enviar um e-mail ou interromper o fluxo do usuário.

Ao coletar um endereço de e-mail durante o registro, login, finalização da compra, inscrição na newsletter ou recuperação de conta, os sites normalmente confirmam que a pessoa que envia o formulário controla o endereço. Os métodos de verificação atuais exigem que os usuários saiam do seu site, troquem de app para verificar a caixa de entrada, copiem um OTP ou cliquem em um link de verificação. Essa interrupção aumenta o abandono de sessões e a desistência de usuários humanos e agentes automatizados. Os usuários costumam ter dificuldades com os métodos de verificação atuais, como e-mails atrasados, links expirados ou códigos não reconhecidos.

Demonstração do prompt do usuário para verificação de e-mail
Demonstração do prompt do usuário para verificação de e-mail

A verificação de e-mail funciona como um aprimoramento progressivo no seu fluxo atual:

  • Sem interrupção: a verificação ocorre em segundo plano enquanto o usuário preenche o formulário.
  • Não é necessário detectar recursos: os sites adicionam uma entrada de e-mail e uma entrada de token oculta aos formulários. Se o navegador ou provedor não for compatível com a verificação de e-mail ou se ela falhar, o site vai voltar ao fluxo padrão de confirmação por e-mail.
  • Minimizar os riscos de phishing: não há código para copiar nem oportunidade de enviar o usuário para um site falso.

Você pode testar o fluxo na demonstração:

Considerações sobre o teste de origem

Os testes de origem são experimentos para coletar feedback. Por isso, sua participação é fundamental se você participar como uma parte confiante ou um provedor de identidade. Para informar problemas, use os seguintes repositórios do GitHub:

Se você encontrar bugs na implementação do Chrome, registre um problema no seguinte componente:

Você controla a funcionalidade do teste de origem por resposta incluindo o token do teste de origem. Isso permite restringir o recurso a um segmento específico de usuários, como uma população de teste A/B. Se você tiver um grupo de usuários para testes Beta ou acesso antecipado, talvez seja necessário ativar o recurso para eles. Nesse caso, verifique o endereço de e-mail fornecido antes de emitir ou validar o token.

Os testes de origem também têm limites de tráfego para minimizar a dependência dos sites no recurso antes do lançamento. A API do emissor está em desenvolvimento, e você pode esperar mudanças incompatíveis com versões anteriores, além de atualizações na experiência do usuário do Chrome.

Acompanhe mais atualizações no blog e na lista de e-mails evp-announce@chromium.org à medida que o desenvolvimento avança.

Fluxo de verificação de e-mail

As seções a seguir explicam os principais termos e etapas do protocolo ao usar a API Email Verification.

Termos-chave

Os principais termos da API Email Verification são:

  • Verificador: o site que coleta o endereço de e-mail e quer verificá-lo. O verificador também é chamado de parte confiável.
  • Provedor de e-mail: o serviço que fornece o endereço de e-mail do usuário, por exemplo, gmail.com.
  • Emissor: o serviço que gerencia a conta do e-mail do usuário, por exemplo, accounts.google.com. O emissor também é chamado de provedor de identidade.

Em alguns casos, o provedor de e-mail e o emissor operam no mesmo domínio. No entanto, é importante distinguir entre eles porque a API Email Verification usa a sessão ativa no navegador com o provedor de identidade como método de verificação. Por exemplo, para verificar example@gmail.com, o usuário precisa fazer login em google.com com essa conta no mesmo navegador.

Fluxo de protocolo

Arquitetura do fluxo de verificação por e-mail
Arquitetura do fluxo de verificação de e-mail
  1. Apresentação do formulário: a parte confiável veicula um formulário HTML que contém um <input type="email"> e uma entrada oculta marcada com autocomplete="email-verification-token" e um nonce exclusivo por instância.
  2. Entrada de e-mail: quando o usuário insere um endereço de e-mail (selecionando uma sugestão de preenchimento automático ou digitando, colando e saindo do campo blur), o navegador aciona a verificação em segundo plano.
  3. Descoberta e sessão: o navegador consulta o registro TXT do DNS para _email-verification.<email-domain> e descobrir a origem do emissor autorizada do provedor. Em seguida, verifica se o usuário tem uma sessão ativa usando a configuração .well-known/web-identity do emissor e os endpoints de contas da FedCM. Se o domínio não publicar um registro EVP ou não houver uma sessão ativa, o navegador vai interromper a verificação sem pedir nada ao usuário.
  4. Emissão de token: o navegador descobre o issuance_endpoint do provedor em .well-known/email-verification, cria um par de chaves efêmeras e envia uma solicitação HTTP POST usando assinaturas de mensagens HTTP (RFC 9421) com os cookies de sessão próprios do emissor e o endereço de e-mail de destino para receber um token de verificação de e-mail assinado (EVT).
  5. Vinculação e envio de chaves: o navegador vincula o EVT assinado à origem da parte confiável e ao formulário nonce em um JWT de vinculação de chaves (KB-JWT). Quando o usuário envia o formulário, o Chrome preenche a entrada oculta com o token combinado (<EVT>~<KB-JWT>) e mostra uma pequena notificação informando que o provedor de e-mail verificou o endereço.
  6. Validar declarações e KB: o servidor da parte confiante analisa o token <EVT>~<KB-JWT>, valida as declarações esperadas (email, email_verified, aud, nonce, iat e exp) e verifica a assinatura de vinculação de chave com a chave pública efêmera em cnf.jwk.
  7. DNS e chaves públicas: a parte confiável consulta o registro TXT do DNS _email-verification.<email-domain> para confirmar se ele corresponde à declaração iss do token. Em seguida, busca os metadados .well-known/email-verification e as chaves públicas do emissor em jwks_uri.
  8. Verificar EVT e concluir: a parte confiável verifica a assinatura do emissor EVT usando o JWKS público do provedor. Se nenhum token for recebido ou se alguma etapa de validação falhar, o site vai voltar ao processo de confirmação de e-mail atual.

Na primeira vez que um usuário verifica um endereço de e-mail, o Chrome mostra uma solicitação de permissão (uma caixa de diálogo no computador ou uma página inferior no Android) antes de pedir um token. Se concedida, essa permissão é lembrada por endereço de e-mail em todos os sites participantes.

Configurações do Chrome

Os usuários podem gerenciar os e-mails verificados:

  • No computador, acesse Configurações > Preenchimento automático e senhas > Dados de contato > E-mail verificado (ou abra chrome://settings/contactInfo).
  • No Android, em Configurações > Endereços e mais > E-mail verificado

Os usuários podem desativar o recurso completamente ou gerenciar endereços de e-mail verificados individuais.

Considerações sobre casos de uso

A verificação de e-mail é um aprimoramento progressivo no seu fluxo atual que remove a necessidade de um usuário sair do seu site para recuperar uma OTP ou clicar em um link. Os sites podem adicionar os campos de verificação de e-mail a todos os formulários relevantes, como logins, inscrições em newsletters, criação de contas e recuperação de senhas. O EVP só é acionado se o navegador for compatível com ele. Se nenhum código for recebido no envio ou se alguma das etapas de validação falhar, você poderá voltar ao fluxo padrão de confirmação por e-mail. Isso também significa que não há detecção de recursos para a API. O site do verificador trata o EVT como opcional, processando-o se ele estiver presente na solicitação.

A verificação de e-mail confirma que o usuário tem uma sessão ativa com o provedor do endereço de e-mail. Ele não verifica se o e-mail chegou ao usuário. Talvez você ainda queira enviar e-mails de boas-vindas ou de integração e precise pedir ao usuário para verificar as configurações de spam.