Deixa um sistema possuir a identidade
O formulário de login recolhe um pedido. O sistema de autenticação decide se esse pedido estabelece uma identidade e emite a sessão em que o resto da aplicação confia. Manter essa responsabilidade num só lugar evita que cada rota invente a sua própria interpretação de um utilizador ligado.
O supastack compõe o Better Auth para identidade e gestão de sessões. O código da aplicação resolve a sessão em fronteiras protegidas e relaciona-a com um workspace. A interface pode mostrar estados de acesso úteis, mas o estado de cliente não deve tornar-se prova de que uma operação é autorizada.
A regra tem de valer em cada superfície que o produto entrega. Os clientes web, mobile e desktop devem consumir a mesma decisão de identidade em vez de a implementarem três vezes — três interpretações de «sessão iniciada» é de onde vêm os bugs de conta.
Escolhe os métodos de login deliberadamente
Cada método troca fricção por superfície de ataque e uma dependência externa. As palavras-passe precisam de fluxos de reposição e limitação de taxa. Magic links e códigos de uso único dependem da entregabilidade do email. O OAuth delega a identidade a fornecedores como Google, GitHub ou Apple — e herda as suas falhas, ecrãs de consentimento e regras de callback.
O supastack compõe-nos através do Better Auth — OTP por email, palavra-passe, magic link, OAuth, com dois fatores e passkeys disponíveis — atrás de uma única decisão de identidade. Entrega o conjunto mais pequeno de que a tua audiência realmente precisa; cada método adicional é outro caminho de callback, outro modo de falha e outro fluxo para verificar antes do lançamento. O guia de autenticação cobre a ligação.
Quando uma pessoa pode iniciar sessão de mais de uma forma, decide como os métodos se juntam. Uma conta Google e um magic link por email que resolvem para o mesmo endereço devem aterrar numa só identidade, não em duas. As regras de ligação de contas fazem parte da decisão de identidade, e errá-las cria utilizadores duplicados que surgem meses depois como dados misteriosamente em falta.
As sessões são a credencial que importa
Depois do login, a sessão — não a palavra-passe — é o que cada pedido transporta. As suas regras de expiração, armazenamento e invalidação definem a verdadeira postura de segurança. Uma sessão que sobrevive ao logout, ou uma que um membro removido do workspace continua a usar, é uma falha de autenticação que nenhum ecrã de login polido corrige.
Decide o ciclo de vida desde o início: quanto tempo vivem as sessões, se os utilizadores podem ver e revogar as suas sessões ativas, e o que uma mudança de palavra-passe, de email ou de workspace lhes faz. A gestão de sessões existe como módulo no kit precisamente porque estas decisões são fáceis de adiar e caras de acrescentar depois.
Relaciona a sessão com o registo pedido
Estar ligado não concede acesso a todos os registos. Resolve o workspace do utilizador no servidor e inclui esse limite em leituras e mutações. Um identificador de tarefa ou link de recuperação é uma referência ao trabalho, não uma permissão para o obter — o post sobre limites de workspace cobre esse lado da fronteira em detalhe.
Resolve o âmbito numa ordem fixa: autentica a sessão, carrega a adesão, depois lê ou escreve com esse contexto de workspace — nunca ao contrário. O middleware pode redirecionar um visitante anónimo, mas não pode autorizar a operação; a verificação pertence à ação de servidor ou ao handler de rota onde o registo é tocado.
As contas têm um ciclo de vida, não apenas um começo
O aprovisionamento é o primeiro teste dessa fronteira. Quando um utilizador se regista, o workspace e os registos de propriedade que se seguem têm de ser seguros de criar mais de uma vez — os hooks de ciclo de vida podem ser repetidos por fornecedores, retries ou ferramentas de suporte. Um evento duplicado deve ser um no-op, não uma organização duplicada.
O fim do ciclo de vida merece o mesmo cuidado. Mudanças de email, reposições de palavra-passe, remoção de membros, eliminação de conta e exportação de dados são cada um pequenos fluxos com os seus próprios casos de abuso — um link de reposição que funciona duas vezes, uma exportação que expõe registos de um colega. O supastack entrega exportação GDPR e gestão de sessões por esta razão; seja sobre o que construíres, orçamenta os fluxos aborrecidos.
Testa o ciclo de vida, incluindo o fim
Um teste de login bem-sucedido é útil mas incompleto. Exercita credenciais inválidas, códigos de verificação expirados ou reutilizados, pedidos anónimos e acesso entre workspaces. Verifica que terminar sessão invalida a sessão e que um cliente que regressa não pode continuar a usar um ecrã previamente autorizado para trabalho protegido.
Distingue testes de handler de aceitação em deployment. Um adaptador em memória pode estabelecer a semântica de um handler de auth real sem provar persistência Postgres ou um callback de fornecedor. Verifica o origin configurado, o caminho de callback, o restauro de sessão e o logout com as dependências deployed antes de afirmares que o fluxo completo de login funciona.
- Credenciais inválidas e códigos de verificação expirados ou reutilizados são rejeitados.
- Pedidos anónimos e entre workspaces não recebem dados protegidos.
- O logout invalida a sessão — um cliente obsoleto não pode continuar a agir.
- Os registos aprovisionados mantêm-se idempotentes quando os hooks de ciclo de vida repetem.
- Os callbacks de fornecedor real funcionam no origin configurado — verificado, não assumido.
Perguntas frequentes de autenticação
As perguntas abaixo surgem quando o formulário de login está feito e o sistema tem de continuar a funcionar.
- O middleware chega para proteger rotas? — O middleware é um redirecionamento conveniente, não uma camada de autorização. Cada ação de servidor e rota resolve a sessão e o workspace por si própria; guardas ao nível da página escondem ecrãs sem autorizar operações.
- Construir a auth eu próprio ou usar uma biblioteca? — A semântica de sessões raramente é onde um SaaS se diferencia. Uma biblioteca mantida como o Better Auth atrás de limites de módulo claros dá-te primitivas testadas enquanto mantém as decisões que importam — delimitação, ciclo de vida — no teu código.
- Como se relacionam sessões e workspaces? — A sessão identifica a pessoa; o workspace identifica os registos que ela pode tocar. Resolve a adesão no servidor em cada pedido e nunca confies num ID de workspace que o cliente envia.
- O que esperam os clientes B2B da autenticação? — Workspaces de equipa com papéis, login OAuth, visibilidade e revogação de sessões, e um rasto de auditoria. Dois fatores e passkeys são cada vez mais esperados para papéis de admin.
- O que parte a autenticação em produção? — Normalmente as pontas: um URL de callback que só existe localmente, um hook que aprovisiona duas vezes, uma sessão que sobrevive a uma adesão. Testa os fins dos fluxos, não apenas os começos.