O Supabase Auth é o sistema de login integrado no Supabase: guarda os utilizadores na base de dados Postgres do seu projeto, autentica-os por palavra-passe, magic link, código de uso único ou através de um fornecedor como o Google, e emite a sessão que as regras da sua base de dados leem. Para adicionar login a uma aplicação web, peça ao seu criador de apps com IA os métodos de login e os perfis, e depois verifique três definições no painel do Supabase: o Site URL, os URLs de redirecionamento e o remetente dos emails.
Este guia explica o que faz cada peça, que escolhas contam e que frases pôr no prompt. Para as regras de acesso em si, leia o nosso guia de Supabase row level security.
O que o Supabase Auth faz e o que não faz
O Supabase Auth prova quem é o utilizador; não decide o que esse utilizador pode ver. A sua documentação lista os métodos de login: palavra-passe, magic link, palavra-passe de uso único, login social (Apple, Google, GitHub e qualquer fornecedor OAuth2 ou OIDC), telefone através de fornecedores como a Twilio, e início de sessão único empresarial SAML. Os dados dos utilizadores ficam num esquema especial da sua própria base de dados Postgres.
O que um utilizador pode fazer é uma segunda camada. O cliente Supabase envia o token do utilizador em cada pedido, e as políticas de row level security da base de dados usam-no para filtrar as linhas. A autenticação responde a "quem é esta pessoa?", e as políticas respondem a "que linhas pode esta pessoa ler ou alterar?". Uma app com login mas sem políticas está aberta.
Que método de login escolher
Escolha o método que corresponde ao comportamento habitual dos seus utilizadores: Google para um público de consumidores ou startups, email e palavra-passe para ferramentas profissionais, magic link quando as pessoas entram raramente. Cada um tem um custo, resumido abaixo.
| Método | Indicado para | Vantagens | Desvantagens |
|---|---|---|---|
| Email e palavra-passe | Ferramentas profissionais, portais de cliente | Familiar, funciona com qualquer endereço de email, sem terceiros | Exige emails de confirmação e de recuperação; os utilizadores esquecem-se das palavras-passe |
| Magic link ou código por email | Logins raros, clientes não técnicos | Nenhuma palavra-passe para guardar ou esquecer | Cada login envia um email, por isso a entregabilidade e os limites de envio contam |
| OAuth (Google, GitHub) | Apps de consumo, startups, ferramentas para programadores | Um clique, sem recuperação de palavra-passe, sem email a enviar | É preciso criar as credenciais no fornecedor e registar o URL de redirecionamento; nem todos os clientes têm a conta |
| Código por telefone | Mercados onde o telefone é a identidade | Rápido no telemóvel | Exige uma conta num fornecedor de SMS, e cada mensagem é cobrada por esse fornecedor |
| SSO empresarial (SAML) | Venda a grandes empresas | As empresas gerem o acesso de forma centralizada | Configuração por cliente; consulte os requisitos do plano na página de preços do Supabase |
Confirmação por email e recuperação da palavra-passe
Com a confirmação por email ativa, um novo utilizador não pode entrar enquanto não clicar na ligação da mensagem. A página de configuração do Supabase indica que, se a desligar, o email é tratado como confirmado sem qualquer verificação. Mantenha-a ativa em tudo o que tenha utilizadores reais: sem ela, qualquer pessoa pode criar uma conta com um endereço que não é seu.
A recuperação da palavra-passe funciona da mesma forma: o utilizador pede uma ligação, recebe um email e chega a uma página da sua app onde escolhe uma nova palavra-passe. Os dois fluxos dependem de duas coisas que controla: as definições de redirecionamento abaixo e o remetente dos emails. Se uma ligação de confirmação abrir "localhost" ou uma página de erro, a causa são quase sempre as definições de redirecionamento.
Sessões: o que acontece depois do login
Depois do login, o Supabase entrega ao navegador um token de acesso de curta duração e um token de renovação, e a biblioteca cliente renova-os sem pedir ao utilizador que volte a entrar. Segundo a documentação das sessões, o token de acesso é um JWT que expira ao fim de 1 hora por predefinição, e cada token de renovação só pode ser usado uma vez. Se um token de renovação antigo for reutilizado fora de uma janela curta, a sessão inteira é terminada.
Para quem usa um criador de apps, o ponto prático é que raramente escreve código de sessão. Peça "manter os utilizadores com sessão iniciada" e "redirecionar para a página de login quando não houver sessão", e a app gerada usa a biblioteca cliente para o resto.
auth.users versus uma tabela profiles
Guarde o registo de login em auth.users e tudo o resto sobre a pessoa numa tabela sua, normalmente chamada profiles. O guia do Supabase sobre gestão dos dados dos utilizadores explica porquê: o esquema auth não é exposto na API automática, por isso a sua app não o pode ler diretamente. O padrão recomendado é uma tabela pública profiles cujo id referencia auth.users com on delete cascade, com row level security ativa, e um trigger que cria a linha do perfil após cada registo.
O mesmo guia avisa que um trigger com erros pode bloquear os registos, por isso teste-o com uma conta nova real após cada alteração à tabela. É uma causa frequente de "Database error saving new user" depois de a IA editar o esquema.
Perfis: administrador, membro, cliente
Guarde o perfil numa tabela sua, não no registo de login, e deixe a row level security aplicá-lo. Uma coluna como role em profiles serve para uma organização. Quando a mesma pessoa pode pertencer a várias empresas ou espaços de trabalho, use antes uma tabela memberships (utilizador, organização, perfil), para que a mesma pessoa possa ser administradora numa e cliente noutra.
Esconder um item do menu aos clientes não é segurança: é a base de dados que tem de recusar o pedido. Uma política como "um cliente só pode ler as faturas em que client_id corresponde à sua própria associação" faz isso. Nunca deixe os utilizadores editar a sua própria coluna de perfil; a política em profiles deve permitir atualizar o nome e o avatar, mas não o perfil.
Registo só por convite para ferramentas internas e portais
Para uma ferramenta interna ou um portal de cliente, desative o registo aberto e crie contas apenas por convite. O Supabase tem a definição "Allow new users to sign up"; quando está desativada, só os utilizadores existentes podem entrar. O convite em si, que cria o utilizador, atribui o perfil e envia o email, tem de correr no servidor, numa edge function, porque precisa de uma chave secreta que nunca deve chegar ao navegador.
O fluxo a pedir: um administrador introduz um email e um perfil, o servidor cria o utilizador e a linha de associação, e a pessoa convidada recebe uma ligação para definir a palavra-passe. Os nossos guias sobre ferramentas internas e portais de cliente mostram onde isto se encaixa numa app completa.
Site URL e URLs de redirecionamento
O Site URL é o endereço predefinido para onde o Supabase reencaminha os utilizadores, e os URLs de redirecionamento são uma lista de permissões de outros endereços que pode usar. A documentação dos URLs de redirecionamento diz que o Site URL começa em http://localhost:3000 e tem de ser alterado para o seu endereço de produção, porque as confirmações por email e as recuperações de palavra-passe dependem dele.
Adicione todos os endereços reais a partir dos quais a sua app é servida: o domínio de produção, o domínio próprio se tiver um, e qualquer endereço de pré-visualização onde teste. A documentação recomenda caminhos exatos em produção e carateres universais sobretudo para desenvolvimento local e pré-visualizações. A falha clássica é uma app publicada cujos emails continuam a apontar para localhost, ou um domínio próprio adicionado mais tarde e nunca registado.
Limites de email e SMTP personalizado
O servidor de email integrado do Supabase serve apenas para testes: em novembro de 2026, a sua documentação indica que está limitado a 2 mensagens por hora, entrega apenas a endereços da equipa da sua organização e não oferece garantia de entrega. Estes números podem mudar sem aviso, por isso leia a página do SMTP personalizado antes do lançamento.
Antes de chegarem utilizadores reais, ligue o seu próprio fornecedor (a página lista Resend, AWS SES, Postmark, SendGrid, ZeptoMail e Brevo como exemplos). A mesma página refere que o SMTP personalizado começa em 30 mensagens por hora, ajustáveis na página de limites, e recomenda autenticar o domínio de envio com DKIM, SPF e DMARC. Se o seu primeiro utilizador de teste nunca receber o email de confirmação, é esta a razão, não um erro da sua app.
Como o Cadrant configura tudo
O Cadrant, o nosso criador de apps, usa o Supabase Auth num projeto Supabase que pertence à sua própria conta Supabase, pelo que as contas dos utilizadores continuam a ser suas. Segundo a nossa documentação de autenticação, gera as páginas de login e de registo, configura o registo com email e palavra-passe, protege as rotas que exigem sessão e gere as sessões. Os fornecedores OAuth como o Google são ativados por si no painel do Supabase, em Authentication, Providers.
A IA escreve as migrações com row level security nas tabelas por utilizador e pode ler o esquema e as políticas atuais antes de os alterar. Os perfis são descritos no prompt e guardados em colunas ou tabelas da sua base de dados. Os segredos, como a chave de um fornecedor de email, ficam em variáveis de ambiente por trás de edge functions. Limites a conhecer: o Site URL, os URLs de redirecionamento, as credenciais dos fornecedores e o SMTP personalizado são definições do Supabase que verifica você mesmo, e deve testar cada perfil à mão antes de convidar clientes. Veja também a nossa visão geral do Supabase com um criador de apps com IA.
Frases de prompt para colar no seu criador de apps com IA
Descreva as pessoas e as regras, não o código. Estas frases funcionam na maioria dos criadores:
- "Adiciona login com email e palavra-passe e com Google. Os utilizadores têm de confirmar o email antes de entrar."
- "Cria uma tabela profiles ligada aos utilizadores de autenticação, preenchida automaticamente no registo, com uma coluna role (admin, member, client). Os utilizadores podem editar o nome, mas nunca o perfil."
- "O registo está fechado. Só um administrador pode convidar um utilizador por email e escolher o seu perfil, a partir de uma função no servidor."
- "Um cliente vê apenas os seus próprios registos. Um membro vê toda a equipa. Um administrador vê tudo e gere os utilizadores. Aplica isto com row level security, não apenas na interface."
- "Adiciona uma ligação Esqueci-me da palavra-passe e uma página para definir uma nova. Redireciona para a página de login os utilizadores sem sessão."