For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/web/authentication.md (or send Accept: text/markdown).
Autenticação
Métodos de acesso, sessões e segurança da conta.
Crie e verifique uma conta real
Autenticação significa provar quem está usando o aplicativo. Inicie Postgres e execute migrações usando primeiro o guia de banco de dados e depois deixe o servidor Web em execução. Abra http://localhost:3000/auth,, escolha a inscrição por e-mail/senha, digite seu nome, e-mail e senha e envie. Mantenha EMAIL_PROVIDER=local para este primeiro teste.
Quando um fluxo solicitar um código de e-mail, abra http://localhost:3000/mail-preview em outra guia do navegador, encontre a mensagem mais recente desse endereço e copie seu código de volta no formulário de login. Solicite um novo código se ele expirar. Essas mensagens ficam na caixa de saída local; verificar repetidamente uma caixa de entrada externa não os encontrará. Saia e entre novamente para confirmar se a conta apoiada pelo banco de dados funciona.
Se a inscrição relatar uma conexão com o banco de dados ou um erro de tabela ausente, conclua a configuração do banco de dados em vez de ativar o login social. Os botões Google, GitHub, Apple, X e Microsoft precisam de seu próprio aplicativo de provedor e configurações de retorno de chamada; habilite um somente após a conclusão do guia do provedor. Better Auth é o mecanismo padrão enviado e não precisa de uma conta de autenticação paga para login de email local.
Escolhe os métodos de login ativados
A base inclui email/palavra-passe, OTP e auth social configurável. O Better Auth possui identidade e sessões, enquanto a aplicação compõe a configuração de fornecedores e a entrega transacional de OTP.
Ativa apenas os fornecedores sociais que configuraste. Os segredos de cliente de fornecedores e o segredo de auth ficam no servidor.
Liga a identidade a um workspace
Handlers autenticados resolvem o estado de sessão antes de aceder a registos do workspace. O aprovisionamento de workspace deve permanecer idempotente para que repetir um hook de ciclo de vida não crie registos de propriedade duplicados.
Verifica o comportamento de sessão
Testa login, OTPs inválidos ou expirados, consumo de utilização única, logout e acesso anónimo negado. Testes com adaptador em memória cobrem a semântica do handler; a persistência em base de produção e callbacks reais de fornecedor exigem aceitação separada.
Instalação e configuração
O Better Auth é o motor predefinido (AUTH_PROVIDER=better-auth); existe um motor Auth.js para equipas que se padronizam nele. Os métodos ativados declaram-se por provider: email/password, códigos de utilização única entregues por email transacional e sign-in social para Google, Apple, GitHub, Microsoft e Twitter.
Cada provider social ativa-se com o seu flag AUTH_<PROVIDER>_ENABLED mais o client id e secret correspondentes. O secret de autenticação, os secrets dos providers e as chaves de assinatura de sessão são configuração apenas de servidor.
AUTH_PROVIDER=better-auth
AUTH_SECRET=generate-a-long-random-value
AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…Fluxo de implementação
A superfície /auth renderiza os métodos configurados; o servidor compõe o motor em auth-runtime e resolve a sessão em cada fronteira protegida. Um primeiro acesso bem-sucedido provisiona o workspace pessoal do membro de forma idempotente — hooks de ciclo de vida repetidos nunca devem criar um segundo registo de propriedade.
A segurança da conta vive em /settings/security: alteração de password, sessões ativas e passkeys onde a build as ativa. Mantém restauro de sessão, revogação no logout e negação entre workspaces como comportamento aplicado no servidor, não como estado da interface.
Verificação e resolução de problemas
Exercita o acesso, códigos OTP inválidos e expirados, consumo de utilização única, cerimónias de passkey em origens HTTPS, retornos de callback social, logout e negação anónima. Regista cada URI de redirect do provider antes de testar callbacks, e verifica que uma sessão revogada não pode continuar a realizar trabalho protegido.