Configuração
1
Coloque o ambiente em federado
organization:update.2
Leia o segredo de identidade
api_keys:write — este segredo emite sessões verificadas, então lê-lo é
possuí-lo, e uma trava de leitura seria a trava errada. Ele é criado na primeira
leitura: até você tê-lo lido, não existe HMAC que ele pudesse verificar.3
Coloque no ambiente do seu servidor
Assine a afirmação
external_id e nada mais. Sem timestamp, sem e-mail, sem
concatenação.
Boot
200 (ou 201 quando o contato foi criado)
Os três desfechos do hash
Um hash errado é recusado de saída e nunca rebaixado a não verificado. Aceitar em
silêncio uma assinatura ruim tornaria invisível um erro de digitação no seu código
de HMAC — você subiria e descobriria muito depois.
O que uma sessão sem prova não faz
Um boot sem hash afirma umexternal_id e não comprova nada — e é uma chamada
que qualquer um que saiba o external_id de alguém consegue fazer do navegador.
Então a sessão que ele emite para nas rotas onde essa afirmação passaria a
importar, cada uma com 403 unverified_session:
GET /v1/contact/me não está na lista: o boot já respondeu com o contato que
resolveu, então barrar isso não fecharia nada.
Sessões anônimas não são afetadas. A sessão de visitante também é não
verificada, mas não há quem personificar — a linha foi criada pela mesma chamada
de boot que agora a segura, então os dados dela são do próprio chamador por
construção. A regra é sobre a única combinação em que a conta do outro lado é de
outra pessoa: não verificada e identificada.
O caminho para passar é o que você ia querer em produção de todo jeito:
configurar o segredo de identidade e mandar o hash.
Um boot sem prova não reescreve perfil
Um boot sem hash pode criar um contato, e é sempre um avistamento. O que ele não pode é mudar oname ou o email de um contato que já existe.
Esses dois são para onde vão os avisos de segurança e de onde sai a claim
email do JWT. Se uma afirmação sem prova pudesse sobrescrevê-los, quem a fez
passaria a receber os avisos da vítima. Um contato que a própria chamada acabou
de criar não tem dono anterior de quem tirar nada, então fica com o que chegou.
O e-mail é atributo, sempre
Esta é a regra que mantém o modo federado seguro, e ela é estrutural em vez de uma verificação. Um e-mail que chega por/v1/boot é guardado na linha do contato. Ele não
resolve para um contato existente, e não vira aresta de identidade.
O HMAC comprova o external_id e só ele. Se um e-mail na mesma requisição pudesse
resolver para um contato, então um hash válido para o seu próprio id somado ao
e-mail de outra pessoa alcançaria os dados dessa pessoa. É a forma clássica de
tomada de conta, e está fechada por construção.
Para comprovar um e-mail no modo federado, envie um
magic link — o único fluxo que promove um
e-mail de atributo a identidade comprovada, e funciona nos dois modos.
Boot anônimo
Boot semexternal_id é um avistamento de visitante, e funciona nos dois modos:
anonymous_id e
external_id juntos, o visitante é absorvido pelo contato identificado e a
atribuição vem junto.
Envie as UTMs da página, onde elas de fato estão.
Rotacionando o segredo
Modos de falha
GET /v1/organization/environments/{id}/identity é relegível de propósito: o seu
servidor precisa do valor numa variável de ambiente, e um segredo que só pode ser
visto uma vez é um segredo que alguém cola num chat.