Autenticação, login e MFA — ingestia.io Documentation

This page has not been translated yet — you are reading the Portuguese version. View in Portuguese

Selo de estado: GA-candidato (login por Google/e-mail-senha e MFA TOTP provados por testes) · SSO empresarial (SAML/OIDC) e login pelo udiApps = Preview · Atualizado em 2026-09-17. Fonte de estado: matriz de estados do produto (verdade de produção; SSO). Limite atual do produto = Preview.

Esta página cobre como uma pessoa entra no ingestia.io e como o dono do workspace endurece o acesso às contas. Para provisionamento automático por IdP corporativo (SAML/OIDC + SCIM), veja SSO e SCIM.

O que é#

A autenticação decide quem é você (identidade). É diferente de o que você pode fazer (papéis/RBAC) e de quais linhas você vê (RLS). Uma pessoa pode participar de vários workspaces com a mesma identidade de login.

Forma	Como funciona	Estado
Google	Login social (Google Sign-In). Restrição opcional por domínio Google Workspace.	`GA-candidato`
E-mail + senha	Cadastro self-service; senha guardada como hash (scrypt), nunca em texto. Definida no cadastro — não há troca nem redefinição por autoatendimento.	`GA-candidato`
MFA (TOTP)	Segundo fator por app autenticador (Google Authenticator, Authy, 1Password…).	`GA-candidato`
Login pelo udiApps	Entrada a partir do gestor central udiApps (handshake assinado).	`Preview`
SSO corporativo (SAML 2.0 / OIDC)	IdP da empresa (Okta, Entra ID, Google Workspace). Ver SSO e SCIM.	`Preview`

Modo de desenvolvimento

Sem nenhuma credencial de auth configurada no ambiente, a instância roda em modo dev aberto (para desenvolvimento local). Em produção isso é bloqueado: sem Google nem credenciais o deploy não se anuncia saudável (verdade de produção — ver Status e limitações).

Para que serve#

Dar a cada pessoa uma identidade única e auditável (a trilha de auditoria registra userEmail).
Exigir segundo fator de todas as contas — não só das sensíveis: na versão implementada o MFA é obrigatório para qualquer acesso logado.
Permitir entrada federada por SSO corporativo (Preview) sem senha local.

Plano e permissões#

Login e MFA: todos os planos.
SSO/SCIM: a partir de Scale (marcado Preview) — ver Planos.
Quem controla: ninguém escolhe. Na versão implementada o MFA é obrigatório para qualquer acesso logado: entrar sem segundo fator configurado leva direto à tela de configuração de MFA, e não há como sair dela para o produto. Cada pessoa configura o próprio autenticador; gerir pessoas é ação de admin/owner (member.manage).
Não existe "exigir MFA de um membro". O cadastro de pessoa tem uma marca com esse nome, mas ela não tem efeito: nenhum caminho de login a consulta. Como o MFA já é obrigatório para todo mundo, a marca não muda nada — e ela não pode ser usada para dispensar ninguém.

Passo a passo — ativar MFA (TOTP)#

Abrir a configuração de MFA
No seu perfil, escolha Ativar verificação em duas etapas. A plataforma gera um segredo TOTP e um QR Code.
Registrar no app autenticador
Escaneie o QR Code (ou digite o segredo) no seu app (Google Authenticator, Authy, 1Password, etc.). Ele passa a gerar um código de 6 dígitos que muda a cada 30 s.
Confirmar o código
Digite o código atual para confirmar o vínculo. A partir daí, todo login passa a exigir senha e o código do momento.

O segredo TOTP é guardado cifrado (AES-256-GCM) no servidor e nunca sai em relatórios, DSAR ou logs.

Ressalva de cadastro legado — a mesma que consta em Credenciais e rotação

A cifra em repouso vale para todo cadastro novo: ativar (ou reativar) o MFA grava a semente cifrada. O leitor, porém, tolera semente legada em texto plano: se a decifra falhar, o valor guardado é usado como está. Isso existe para não quebrar o login de quem registrou o MFA antes da cifra — e não há migração que reescreva cadastros antigos, então "cifrado em repouso" descreve o que é gravado hoje, não uma garantia retroativa sobre todo registro existente. Esta é a mesma ressalva de Credenciais e rotação; as duas páginas afirmavam coisas diferentes, e é esta a versão que corresponde ao código. Reativar o MFA (desativar e ativar de novo) regrava a semente cifrada.

Registrar a ressalva não é afirmar que exista segredo em texto plano em algum ambiente: é dizer que o produto ainda aceita ler um, e que nenhuma varredura de valores foi feita (nem seria pedida) para escrever esta página.

Exemplo#

Na Comércio Aurora (fictícia), Maria (owner) entra com Google. João (admin) usa e-mail + senha e, por operar fontes e pessoas, ativa o MFA. A partir daí, o login dele pede senha e o código de 6 dígitos do app autenticador.

Resultado esperado#

Login bem-sucedido cria a sessão e leva à área logada.
Com MFA ativo, login sem código válido é negado (não entra "só com senha").
A entrada fica registrada na trilha de auditoria do workspace.

Segurança#

Senhas: hash scrypt; a plataforma nunca guarda nem exibe a senha em texto.
MFA: verificação TOTP com janela de tolerância; segredo cifrado em repouso nos cadastros novos, com a ressalva de leitura de cadastro legado descrita acima.
Domínio Google (opcional): o dono pode restringir o login social a um domínio Workspace específico (hd), recusando contas fora dele.
Convite de membro: o cadastro de uma pessoa não emite senha. Ele emite um link de ativação de uso único, com validade, guardado como hash; a pessoa define a própria senha ao aceitar (ver Usuários). Link perdido ou vencido se resolve reenviando o convite — não existe "gerar nova senha". Ver Credenciais e rotação.
O time nunca pede sua senha nem o valor de uma chave — ver Suporte.

Limites#

Recuperação de MFA: não existe, nem por autoatendimento nem pelo produto. Não há códigos de recuperação de uso único, e não há ação de admin, de owner ou de suporte dentro do produto que zere o segundo fator de outra pessoa — procuramos e ela não existe no código. Quem perde o app autenticador fica sem caminho de volta pela interface; resolver isso hoje é intervenção fora do produto. Guarde a semente do autenticador ao configurar.
Troca de senha: não há tela de "alterar minha senha" nem fluxo de "esqueci minha senha". A senha de login é definida no cadastro; trocá-la depois é caso de suporte. Quem entra por Google ou SSO não tem senha local.
Sessão: a sessão é um token assinado guardado no navegador; o servidor não mantém lista de sessões, então não há "encerrar sessões em todos os dispositivos" nem revogação de sessão ao trocar credencial.
SSO/login udiApps: Preview — sem SLA; comportamento pode mudar.
E-mail transacional pode não estar habilitado em todos os ambientes atuais; prefira os canais in-app quando o fluxo depender de e-mail.

Erros comuns e diagnóstico#

Sintoma	Causa provável	O que fazer
Login recusado com senha certa	MFA ativo e código ausente/errado	informe o código atual do app autenticador
Código TOTP sempre inválido	relógio do celular fora de hora	sincronize a hora automática do aparelho
Google recusa a conta	restrição de domínio Workspace (`hd`)	use uma conta do domínio permitido
"Auth não configurada em produção"	ambiente sem Google nem credenciais	operador deve configurar as envs de auth

Relacionados#

Última revisão: 2026-09-17.

Estado & evidência: login Google/e-mail-senha + MFA TOTP provados por testes (limite atual do produto = Preview); SSO/login udiApps = Preview. Fonte: matriz de estados do produto.