Pular para o conteúdo principal

Autenticação

Chamadas REST usam Bearer token no header. A chave secreta define o ambiente: sk_test roda em sandbox, sk_live em produção. Nunca exponha a secret no front: ela é só server-side. curl · Criar a sessão · no terminal
Se uma chave sua aparecer fora do seu servidor ou for usada sem a sua autorização, a UNIFOKAL pode revogá-la na hora e avisa por e-mail os owners e admins da conta (Termos, item 3.4). Chave revogada responde 401 invalid_api_key: crie outra no painel e troque na integração. Revogar uma chave, por você ou pela UNIFOKAL, corta também o que ela emitiu e ainda não começou: o link de verificação ainda não usado deixa de abrir e a sessão que o titular ainda não enviou deixa de valer. A verificação já enviada segue, é decidida e chega ao seu webhook. Para trocar a chave sem cancelar nada, use Rotacionar com prazo no painel: a chave antiga continua valendo até o prazo (até 7 dias) e o que ela já criou segue até o próprio vencimento. Todo erro tem a mesma forma: { "error": "<código>", "message": "<texto>" }. Trate pelo error, que é contrato estável dentro de /v1. O message é para humano e pode mudar sem aviso. A lista completa dos que você encontra no primeiro dia está logo abaixo. curl · Os erros que você vai encontrar no primeiro dia · no terminal
Os dois ambientes são mundos separados: um flow_id de produção não existe para uma chave de teste, e o erro que volta é 404 flow_not_found, não um 403 de permissão. Se um flow que você acabou de criar “não existe”, confira o ambiente da chave antes de qualquer outra coisa (veja Sandbox).

Segurança do fluxo

O front recebe do seu backend apenas o sessionId (vs_), escopado a UMA única sessão (uso curto, com TTL). Ele é a credencial do widget: nenhum segredo vai ao navegador. Não é uma chave global: só habilita a captura daquela verificação, então expor por engano não compromete outras sessões nem a sua conta. A sk_ (secret), usada no backend para criar a sessão, é a única credencial sensível e nunca sai do servidor. A captura e o processamento acontecem no UNIFOKAL; o resultado oficial só trafega no webhook assinado para o seu backend. Encontrou uma vulnerabilidade? A política de divulgação responsável diz como relatar, o escopo e o que esperar, e o arquivo /.well-known/security.txt traz os mesmos canais em formato legível por máquina. Os documentos de segurança, privacidade e contrato ficam reunidos na central de confiança.

Acesso da equipe por SSO (SAML 2.0)

A sua equipe pode entrar no painel pelo provedor de identidade da própria empresa, em vez de e-mail e senha por pessoa. Falamos SAML 2.0 no perfil Web Browser SSO, que é o caminho documentado por Okta, Microsoft Entra ID e Google Workspace para aplicações de terceiros. Está incluso: não é add-on, não tem mensalidade e não consome crédito. Quem liga é o dono da conta, em Segurança da conta no painel. A tela mostra os dois valores que você cola no seu provedor (o Entity ID e a URL de retorno, que o Entra chama de Reply URL) e recebe de volta o identificador, a URL de login e o certificado de assinatura que o seu provedor gera. Formato do identificador (NameID): o padrão é o de e-mail (EmailAddress). No Okta, o aplicativo precisa do Name ID format EmailAddress. No Microsoft Entra ID, o identificador padrão é o UPN (user.userprincipalname): se ele não for o e-mail da pessoa, troque a fonte para user.mail ou informe na tela o atributo de e-mail. A tela também aceita o persistente, o não especificado e o transitório. O persistente e o transitório tiram o e-mail do identificador e por isso pedem o atributo em que o provedor envia o e-mail. O pedido de login não fixa a forma de autenticação: o provedor informa a que a pessoa usou. Como fica o segundo fator: quem entra pelo seu provedor não precisa também do nosso código de verificação em duas etapas, porque o segundo fator é o que a sua empresa já exige no próprio provedor. A exigência de duas etapas aqui continua valendo para quem entra por e-mail e senha. Ao exigir SSO, a equipe deixa de entrar por senha. O dono da conta continua conseguindo entrar por senha de propósito: é a saída de emergência para o dia em que o certificado do provedor expirar ou a configuração sair errada, situação em que ninguém mais consegue entrar. Pelo mesmo motivo, você pode cadastrar mais de um certificado ao mesmo tempo e trocar sem janela de queda: cadastre o novo antes de virar a chave no seu provedor. Provisionamento automático (SCIM 2.0). Além de entrar pelo seu provedor, a sua equipe pode ser gerida por ele: Okta e Microsoft Entra ID criam, atualizam e desativam contas daqui pelo protocolo SCIM 2.0 (RFC 7643 e 7644). O ganho de segurança é o desligamento: quem for desativado no seu diretório perde o acesso aqui na hora, com as sessões abertas derrubadas no mesmo instante, sem depender de alguém lembrar de mexer no painel. Para ligar: na tela de Segurança da conta, com a conexão de SSO ativa, o dono da conta gera o token de provisionamento e copia o endereço do SCIM. No Okta, os dois entram em Provisioning como SCIM connector base URL e API token (autenticação HTTP Header); no Entra, como Tenant URL e Secret Token do provisionamento do aplicativo. O token é exibido uma única vez, como as chaves de API: perdeu, rotacione. Rotacionar invalida o anterior no mesmo instante, e revogar interrompe a sincronização sem mexer em quem já foi provisionado. O recorte, dito com todas as letras: o identificador da pessoa (userName) é o e-mail e não se renomeia por SCIM; quem nasce pelo provisionamento entra com o papel padrão da conexão, e o papel de quem já existe nunca é reescrito; grupos não são provisionados (papel por grupo continua sendo do mapeamento do SAML); o titular da conta não é gerenciável por SCIM, de propósito, porque é ele quem mantém a saída de emergência; remover alguém pelo provedor desativa a conta aqui, sem apagar o histórico de quem fez o quê; e uma remoção feita por uma pessoa no painel não é desfeita pelo provedor. Papel por grupo do provedor. Na tela de SSO você informa o atributo em que o seu provedor envia os grupos da pessoa e liga cada grupo a um papel. Quem entra pela primeira vez pelo SSO recebe o papel do grupo mais forte em que está, ou o papel padrão da conexão se nenhum grupo casar. O papel de quem já está na equipe nunca é reescrito pelo grupo, e nenhum grupo dá a titularidade da conta: ela só muda por transferência no painel. Saída avisada pelo provedor. Quando o seu provedor manda o aviso de logout assinado, as sessões abertas por ele para aquela pessoa caem aqui também. A sessão de quem entrou por senha continua de pé, porque o provedor só responde pelo que ele abriu. Aviso sem assinatura válida é recusado. Saída pelo provedor ao sair daqui. Com a opção ligada na tela de SSO, quem entrou pelo provedor e clica em Sair encerra a sessão daqui primeiro e é levado ao provedor para encerrar a sessão por lá, o que pode encerrar também os outros aplicativos da pessoa. A sessão daqui cai sempre, mesmo que o provedor não responda. Antes de ligar, libere no provedor o logout iniciado pelo aplicativo: no Okta, a Single Logout URL é a nossa URL de logout, o SP Issuer é o nosso identificador e o certificado é o nosso certificado de assinatura (deixe Signed Requests desmarcado); no Microsoft Entra ID, a Logout Url é a nossa URL de logout (não ligue Require verification certificates). Vale para quem entrar depois de ligar. Com a opção desligada, Sair encerra só a sessão daqui, e a tela de entrada avisa que a sessão no provedor continua aberta. O que ainda não existe, para você não planejar em cima do que não temos: o login iniciado pelo provedor (o acesso começa sempre pela nossa tela de entrada) e o aviso ao provedor quando a sessão daqui cai sem a pessoa clicar em Sair (expiração, remoção pelo SCIM, encerramento pelo dono da conta).