> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # 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. [Inicie Postgres antes de criar uma conta](https://supastack.dev/pt/docs/web/database.md) [Usar e solucionar problemas de códigos de login de e-mail](https://supastack.dev/pt/docs/web/setup-ai.md) [Configurar login do Google](https://supastack.dev/pt/docs/web/setup-oauth.md) [Adicionar o início de sessão com Google](https://supastack.dev/pt/docs/web/google-sign-in.md) [Adicionar o início de sessão com GitHub](https://supastack.dev/pt/docs/web/github-sign-in.md) [Adicionar o início de sessão com Apple](https://supastack.dev/pt/docs/web/apple-sign-in.md) ## 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__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. ## Seguinte [Organizações e convites](https://supastack.dev/pt/docs/web/organizations.md)