Como Adicionar Login no App Feito com IA: Supabase Auth Passo a Passo [2026]

O app que a IA montou em uma tarde parece pronto até o primeiro usuário perguntar onde fica o botão de entrar. Saber como adicionar login no app é o que separa um protótipo bonito de um produto que guarda dados de gente real. É também a parte que as ferramentas de geração de código mais erram quando recebem um prompt vago. Já vimos tela de login com senha fixa no JavaScript, sessão salva em localStorage sem validação nenhuma e rota de admin protegida só por um if no front.

Na Marfin, todo projeto que nasce com vibe coding e precisa de usuário segue o mesmo caminho. O Supabase Auth cuida da identidade, o Postgres com Row Level Security protege os dados e o Claude Code, a ferramenta que mais usamos, faz a implementação pesada. O Cursor entra quando estamos ajustando telas e fluxos no editor. Esse combo virou padrão porque é barato, roda bem com Next.js e React e aguenta o app crescer sem reescrever a autenticação.

Este guia mostra o processo completo, do projeto vazio no Supabase até o login com Google funcionando em produção. Cobrimos a configuração das chaves, os clientes de navegador e de servidor, a proteção de rotas, as políticas de RLS e os emails transacionais. Também mostramos os prompts que usamos para a IA escrever esse código sem inventar atalhos perigosos, um comparativo com Clerk, Firebase Auth e Better Auth e os preços de setembro de 2026.

Link para esta seçãoComo adicionar login no app: o que muda quando o sistema passa a ter usuários

Antes de abrir o painel do Supabase, vale entender o que o login coloca dentro do seu app. Autenticação responde à pergunta "quem é você" e termina quando o sistema confirma a identidade, seja por senha, link mágico ou conta do Google. Autorização vem logo depois e responde "o que você pode ver e fazer". A maioria dos furos de segurança em apps gerados por IA fica na segunda camada: o usuário loga direitinho e consegue ler o pedido do vizinho trocando um ID na URL.

Quando alguém faz login no Supabase Auth, o servidor de autenticação devolve um JWT de acesso e um refresh token. O JWT expira em uma hora por padrão, e o refresh token renova a sessão sem pedir a senha de novo. Em apps que renderizam no servidor, como os feitos em Next.js, esses tokens ficam em cookies, e o pacote @supabase/ssr lê e reescreve os cookies a cada requisição. O banco recebe o JWT junto com cada consulta, e é assim que as políticas do Postgres sabem quem está pedindo o dado.

Link para esta seçãoO login de mentira que a IA gera quando o prompt é vago

Peça "adicione uma tela de login" a qualquer ferramenta de geração de código sem dar contexto e as chances de receber um formulário que compara email e senha com uma lista dentro do próprio código são altas. Funciona na demo e desaba no primeiro inspecionar elemento. O segundo padrão ruim que encontramos com frequência é o app que chama o Supabase direitinho na hora do login, só que deixa todas as tabelas sem RLS. Na prática, qualquer pessoa com a chave publicável, que vai embutida no JavaScript do navegador, consegue ler o banco inteiro.

Por isso nosso método começa pela arquitetura e só depois chega no prompt. Quando a IA recebe instruções claras sobre onde a sessão é validada e quais tabelas precisam de política, o código já sai no formato certo e a revisão fica rápida.

Link para esta seçãoSupabase Auth: o que vem pronto e por que virou nosso padrão

O Supabase Auth é o módulo de autenticação do Supabase e roda sobre o Postgres do mesmo projeto. Os usuários ficam na tabela auth.users, e qualquer tabela sua pode apontar para esse ID com chave estrangeira. Essa ligação direta com o banco é o principal motivo de usarmos o Supabase Auth em vez de um serviço de login separado. A função auth.uid() fica disponível dentro das políticas de segurança, então a regra "cada um vê só o que é seu" vira uma linha de SQL.

Em métodos de entrada, a lista cobre quase tudo que um app brasileiro precisa. Tem email e senha, link mágico e código OTP por email ou SMS. Tem login social com mais de vinte provedores, como Google, Apple, GitHub, Microsoft, Facebook, LinkedIn e Discord. Tem ainda login anônimo para quem quer testar antes de criar conta, autenticação multifator por TOTP e SSO via SAML para clientes corporativos nos planos pagos. Dá para ligar CAPTCHA com hCaptcha ou Cloudflare Turnstile nas telas de cadastro e usar Auth Hooks para rodar lógica própria, como bloquear emails descartáveis ou adicionar claims personalizadas ao token.

Outra mudança recente que vale conhecer: o Supabase trocou as chaves antigas anon e service_role por chaves publicáveis, com prefixo sb_publishable_, e chaves secretas, com prefixo sb_secret_. Também passou a assinar os JWTs com chaves assimétricas. Na prática, a chave publicável pode ir para o navegador e a secreta fica só no servidor. Além disso, o seu backend consegue validar tokens localmente, sem consultar o servidor de autenticação a cada requisição. Projetos antigos continuam aceitando as chaves legadas, mas recomendamos migrar quando for mexer no login.

Link para esta seçãoO que você precisa ter pronto antes de começar

Este passo a passo parte de um app em Next.js com App Router, que é o que Lovable, V0, Cursor e Claude Code geram com mais frequência quando o projeto precisa de backend. Se o seu app saiu do Lovable em React com Vite, os conceitos são os mesmos. Muda só a proteção de rotas, que passa a acontecer no cliente e no banco. Se você ainda está tirando a ideia do papel, nosso guia de como criar app sem programar mostra o caminho até a primeira versão rodando.

Você vai precisar de uma conta no Supabase com um projeto criado (o plano Free serve) e do código do app em um repositório Git. Também vai precisar de uma conta no Google Cloud, se quiser login com Google, e de um domínio próprio para configurar o envio de emails antes de lançar. Separe uns 40 minutos sem interrupção. A configuração em si é rápida, mas os redirecionamentos entre app, Supabase e Google são onde mais gente trava, então vale testar cada passo antes de seguir para o próximo.

Link para esta seçãoPasso a passo: como adicionar login no app com Supabase Auth

Link para esta seçãoPasso 1: configure as chaves e as URLs de redirecionamento

No painel do Supabase, abra Project Settings e depois API Keys para copiar a URL do projeto e a chave publicável. Coloque as duas no arquivo .env.local do app como NEXT_PUBLIC_SUPABASE_URL e NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY. A chave secreta só entra em variável de ambiente do servidor, sem o prefixo NEXT_PUBLIC_. E só se alguma rota realmente precisar passar por cima do RLS, como um webhook de pagamento.

Depois vá em Authentication e URL Configuration. O campo Site URL recebe o endereço de produção do app. A lista Redirect URLs recebe todos os endereços para onde o Supabase pode mandar o usuário depois de confirmar o email ou logar com Google. Inclua http://localhost:3000/** para desenvolvimento e o domínio final. Se você usa previews da Vercel, dá para liberar um curinga no formato https://*-sua-conta.vercel.app/**. Esquecer essa lista é a causa número um de login que funciona no computador de quem desenvolveu e quebra em produção.

Link para esta seçãoPasso 2: instale o SDK e crie os clientes de navegador e de servidor

Rode npm install @supabase/supabase-js @supabase/ssr e crie dois arquivos utilitários. O cliente de navegador serve para os componentes que rodam no front, como o formulário de login. O cliente de servidor serve para Server Components, Route Handlers e Server Actions, e lê a sessão a partir dos cookies da requisição.

// lib/supabase/server.ts
import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'

export async function createClient() {
  const cookieStore = await cookies()
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll: () => cookieStore.getAll(),
        setAll: (lista) => {
          try {
            lista.forEach(({ name, value, options }) => cookieStore.set(name, value, options))
          } catch {
            // Server Components só leem cookies; o proxy cuida de renovar a sessão
          }
        },
      },
    }
  )
}

O cliente de navegador é ainda mais curto: uma chamada a createBrowserClient com as mesmas duas variáveis. O erro que a IA mais comete aqui é usar o pacote antigo @supabase/auth-helpers-nextjs, que foi descontinuado. Se esse import aparecer no código gerado, peça a troca pelo @supabase/ssr na hora, antes de construir qualquer tela em cima dele.

Link para esta seçãoPasso 3: cadastro e login com email e senha

O formulário de cadastro chama supabase.auth.signUp com email, senha e a opção emailRedirectTo apontando para a rota de confirmação do seu app. Por padrão, o Supabase pede confirmação de email, então o usuário recebe um link e só consegue entrar depois de clicar nele. Para o login, a função é signInWithPassword, e para sair, signOut. Nós preferimos fazer essas chamadas dentro de Server Actions. Assim, a sessão já nasce nos cookies e a página seguinte renderiza no servidor sabendo quem está logado.

Em apps que renderizam no servidor, a confirmação de email usa o fluxo PKCE. No template de email do Supabase, em Authentication e Emails, troque o link padrão por um que aponte para a rota /auth/confirm do seu app passando token_hash e type. Depois crie essa rota chamando supabase.auth.verifyOtp. O mesmo vale para o email de recuperação de senha e para o link mágico. Nós mesmos já quebramos o link mágico e o reset de senha de um painel interno por esquecer essa rota. O sintoma engana: o email chega, o usuário clica e cai de volta na tela de login sem mensagem de erro nenhuma.

Para guardar nome, foto e preferências, crie uma tabela profiles com a coluna id apontando para auth.users. Junto dela, crie um trigger que insere a linha automaticamente quando alguém se cadastra. Assim o app nunca tem usuário sem perfil, e o Claude Code monta esse trigger em segundos se você pedir de forma explícita.

Link para esta seçãoPasso 4: login com Google

Login social aumenta visivelmente a conversão do cadastro, principalmente no celular, onde digitar senha atrapalha de verdade. No Google Cloud Console, crie um projeto, configure a tela de consentimento OAuth e gere um Client ID do tipo aplicativo da Web. Em URIs de redirecionamento autorizados, cole a URL de callback que o próprio Supabase mostra na página do provedor Google, no formato https://seu-projeto.supabase.co/auth/v1/callback. Depois volte ao Supabase, ative o provedor Google na seção de provedores de login e cole o Client ID e o Client Secret.

No app, o botão chama supabase.auth.signInWithOAuth com provider: 'google' e redirectTo apontando para /auth/callback. Essa rota recebe um parâmetro code na URL e troca esse código por uma sessão com exchangeCodeForSession. Em seguida, grava os cookies e redireciona para o painel. Sem essa rota, o Google autentica, o Supabase devolve o código e o usuário fica parado em uma URL cheia de parâmetros. Apple, GitHub e Microsoft seguem o mesmo desenho, e só muda o lugar onde você gera as credenciais.

Link para esta seçãoPasso 5: proteja as rotas no servidor

Esta é a etapa que mais aparece errada em código gerado por IA. Esconder o link do painel de quem está deslogado melhora a experiência, só que a proteção de verdade acontece no servidor. No Next.js, crie o arquivo de middleware (chamado proxy.ts a partir do Next.js 16). Ele cria o cliente de servidor, renova a sessão a cada requisição e manda para /login quem tentar abrir rotas privadas sem sessão válida.

Dentro das páginas e das Server Actions, valide o usuário com supabase.auth.getClaims(), que confere a assinatura do JWT, ou com getUser(), que consulta o servidor de autenticação. Evite getSession() no servidor para decidir acesso. Essa função lê o que está no cookie sem revalidar, e o próprio usuário consegue editar o cookie. Parece detalhe, e é justamente o tipo de coisa que a IA troca sem avisar. Por isso, vale colocar a regra no prompt e no arquivo de instruções do projeto.

Link para esta seçãoPasso 6: ligue o Row Level Security em todas as tabelas

Com o login funcionando, falta garantir que cada usuário acesse só os próprios dados. O Row Level Security é um recurso nativo do Postgres que filtra linhas de acordo com políticas. No Supabase, ele é a última linha de defesa, porque a chave publicável sempre fica exposta no navegador. Uma tabela sem RLS em um projeto Supabase fica aberta para leitura e escrita por qualquer pessoa que tenha essa chave.

alter table public.projetos enable row level security;

create policy "Dono lê os próprios projetos"
on public.projetos for select to authenticated
using ((select auth.uid()) = user_id);

create policy "Dono cria projetos em seu nome"
on public.projetos for insert to authenticated
with check ((select auth.uid()) = user_id);

Repita o padrão para update e delete, e defina default auth.uid() na coluna user_id para o app nem precisar mandar esse valor. Envolver auth.uid() em um select parece estranho, mas faz o Postgres calcular o valor uma vez por consulta em vez de uma vez por linha, o que pesa bastante em tabelas grandes. Depois de criar as políticas, abra o Security Advisor no painel do Supabase. Ele aponta tabelas sem RLS e políticas permissivas demais.

Link para esta seçãoPasso 7: emails transacionais com SMTP próprio

O serviço de email embutido no Supabase existe para testes. Ele tem limite de envio bem baixo por hora e só entrega para endereços de membros da organização. Antes de abrir o cadastro para o público, configure SMTP próprio em Authentication e Emails. Use um provedor como Resend, Postmark, Amazon SES ou Brevo e ajuste os limites de envio na seção de rate limits. Aproveite para traduzir os templates de confirmação, link mágico e recuperação de senha e colocar a marca do app. Email em inglês com remetente genérico cai no spam e derruba a taxa de confirmação.

Link para esta seçãoOs prompts que usamos no Claude Code, no Cursor e no Lovable

A qualidade do login que a IA escreve depende quase toda do contexto que ela recebe. Se você ainda está escolhendo ferramenta, nosso comparativo das melhores IDEs com IA em 2026 ajuda a decidir. O método abaixo funciona em qualquer uma delas.

Link para esta seçãoNo Claude Code

O Claude Code é onde fazemos a implementação completa do login. Ele lê o projeto inteiro, roda os comandos, cria as migrations e testa o fluxo sozinho. Com o servidor MCP do Supabase conectado, ele consulta o schema real, aplica as políticas de RLS e roda o Security Advisor sem sair do terminal. No Opus 4.8, lançado no fim de maio, o controle de esforço permite pedir raciocínio máximo nessa tarefa. É o que recomendamos para qualquer mudança de autenticação.

O prompt base que usamos é mais ou menos este: "Adicione autenticação com Supabase Auth neste app Next.js usando @supabase/ssr. Crie clientes de navegador e servidor, um proxy que renova a sessão e protege /app, login com email e senha e com Google, rota /auth/callback com exchangeCodeForSession e rota /auth/confirm com verifyOtp. No servidor, valide a sessão só com getClaims. Crie a tabela profiles com trigger em auth.users, ative RLS em todas as tabelas públicas com políticas baseadas em auth.uid() e rode o advisor de segurança no final. Antes de codar, me mostre o plano."

Esse último pedido faz diferença: revisar o plano leva dois minutos e evita que ele invente uma tabela de usuários paralela. Com o fluxo aprovado, colocamos essas regras no CLAUDE.md do projeto para que toda sessão futura siga o mesmo padrão.

Link para esta seçãoNo Cursor

No Cursor, que é a IDE que usamos para building no dia a dia, o login costuma aparecer em ajustes menores. Pode ser uma nova tela de perfil, um botão de login com Apple ou uma rota que passa a exigir sessão. O que funciona melhor aqui é criar uma regra de projeto em .cursor/rules com as mesmas diretrizes: pacote @supabase/ssr, validação com getClaims e RLS obrigatório. No chat, mencione com @ os arquivos de cliente do Supabase. Assim o agente do Cursor segue o padrão que o Claude Code já montou, e o projeto fica com um único jeito de ler a sessão.

Link para esta seçãoNo Lovable, no Bolt.new e no V0

O Lovable tem integração nativa com o Supabase e, com o Lovable Cloud, sobe um backend já com autenticação sem você sair do editor. Basta pedir "adicione login com email e Google" no chat que o Agent Mode cria as telas, conecta o provedor e sugere as políticas de RLS. Mesmo assim, confira as políticas no painel do Supabase antes de publicar. Já pegamos casos em que a política criada liberava leitura para qualquer usuário logado. O nosso tutorial de Lovable mostra essa integração em detalhe, com prints de cada etapa.

O Bolt.new também conecta com o Supabase e resolve bem um login simples, então é uma alternativa válida para quem já está construindo por lá. O V0 da Vercel gera ótimas telas de login e cadastro com shadcn/ui e instala o Supabase pela Vercel Marketplace. Costumamos usá-lo para desenhar a interface e depois levar o código para o Cursor. Em qualquer uma dessas ferramentas, trate o login gerado como rascunho e passe pelos passos 5 e 6 deste guia antes de colocar usuário real dentro do app.

Link para esta seçãoSupabase Auth, Clerk, Firebase Auth ou Better Auth: qual autenticação escolher

O Clerk é o concorrente que mais aparece nas nossas conversas com clientes. Ele entrega componentes de login prontos e muito bem desenhados, gestão de organizações para apps B2B e uma configuração excelente. O ponto fraco, para quem já usa Supabase, é manter os usuários em um serviço separado. Dá para integrar os dois com o recurso de third-party auth do Supabase, só que aí são duas contas, duas faturas e mais uma peça para investigar quando a sessão some.

O Firebase Auth é maduro, tem cota gratuita generosa e combina com o Firestore. Faz sentido para apps mobile nativos que já vivem no ecossistema do Google. Em apps web feitos com IA, o banco relacional do Supabase costuma ser mais fácil para a IA modelar. E, na hora de revisar, as políticas de RLS em SQL são mais legíveis que as regras de segurança do Firestore.

Auth.js e Better Auth são bibliotecas open source que rodam dentro do seu próprio app e guardam os usuários no banco que você escolher. Dão controle total e custo zero de licença. Em troca, trazem mais código para manter, mais responsabilidade com segurança e nenhuma integração automática com RLS. Nossa recomendação é direta: se o app usa Supabase como banco, use Supabase Auth. O Clerk entra quando o produto é B2B com organizações complexas desde o primeiro dia. As bibliotecas próprias entram quando existe um time técnico disposto a manter a autenticação no longo prazo.

Link para esta seçãoPreços e planos

O Supabase cobra a autenticação por usuário ativo mensal (MAU), ou seja, cada pessoa que fez login ou renovou a sessão dentro do mês. Os valores abaixo são de setembro de 2026, em dólar, sem impostos nem IOF do cartão internacional.

Na prática, um app que acabou de sair do vibe coding cabe com folga no Free. A mudança para o Pro costuma vir por dois motivos. O primeiro é a pausa automática: um projeto parado por uma semana hiberna, e o primeiro usuário da segunda-feira encontra erro. O segundo é a proteção contra senhas vazadas. Se o produto está virando um SaaS com assinatura, um único cliente pagante já cobre o Pro. Somando o SMS para OTP, cobrado à parte pelo Twilio ou outro provedor, e o serviço de email transacional, que quase sempre tem plano gratuito, o login de um app pequeno custa menos de US$ 30 por mês.

Link para esta seção8 dicas de como adicionar login no app com segurança

1. Ative o RLS antes de criar a primeira tabela com dados de usuário. Deixar para depois é o caminho mais comum para um vazamento: o app vai ao ar, alguém abre o console do navegador e lista a tabela inteira. Coloque no arquivo de instruções do projeto que toda migration nova precisa vir acompanhada das políticas.

2. Teste com dois usuários de verdade. Crie duas contas e cadastre dados na primeira. Depois, pela segunda conta, tente acessar esses dados trocando IDs na URL e chamando a API direto. Esse teste de cinco minutos pega a maioria dos furos de autorização.

3. Configure SMTP próprio e traduza os emails antes do lançamento. O email de confirmação é a primeira mensagem que sua marca manda para o usuário. Remetente com o seu domínio, texto em português e SPF e DKIM configurados mantêm a mensagem longe da caixa de spam.

4. Deixe o login com Google em destaque no celular. Em apps de consumo, o botão social costuma converter mais que o formulário de senha. Mantenha email e senha como alternativa para quem prefere separar a conta do app da conta do Google.

5. Mantenha a chave secreta longe do front. Qualquer variável com prefixo NEXT_PUBLIC_ vai parar no JavaScript do navegador. A chave secreta passa por cima do RLS, então vazá-la equivale a entregar o banco inteiro. Se a IA sugerir usar essa chave em um componente cliente, recuse na hora.

6. Ligue proteção contra bots no cadastro. Formulário de cadastro aberto atrai contas falsas em poucos dias. O Supabase aceita hCaptcha e Cloudflare Turnstile nativamente, e a configuração leva menos de dez minutos.

7. Pense no fluxo de exclusão de conta desde o início. A LGPD garante ao usuário o direito de pedir a eliminação dos dados, e as lojas de aplicativo exigem um botão de excluir conta dentro do app. Crie uma Edge Function que apaga o usuário com a chave secreta e configure on delete cascade nas tabelas relacionadas.

8. Revise o fluxo completo depois de cada deploy. Em uma janela anônima, teste nesta ordem: cadastro, confirmação, login, logout, recuperação de senha e login com Google. Mudar domínio ou variável de ambiente quebra o redirecionamento sem nenhum aviso no build. O nosso guia de deploy de app com IA traz o checklist de variáveis e domínios para essa etapa.

O login é o que transforma um protótipo em produto, e também o que mais cobra caro por atalhos. Com o Supabase Auth, o trabalho pesado de guardar senha, emitir tokens, conversar com o Google e renovar sessão já vem resolvido. Sobra ligar as peças com cuidado: URLs de redirecionamento, rotas de callback, validação no servidor e RLS em todas as tabelas.

Nossa sugestão para a próxima tarde de trabalho é abrir o Claude Code no repositório do app e colar o prompt da seção acima. Revise o plano que ele propõe e rode o teste com dois usuários antes de chamar qualquer pessoa para usar. Com o login de pé, o app está pronto para o próximo passo natural, que é começar a cobrar por ele.

Leia também:

• O que é vibe coding e como começar a programar com IA
• Lovable tutorial: como criar apps com IA do zero
• Como criar app sem programar usando IA
• Deploy de app com IA: como colocar seu projeto no ar
• Lovable vs Bolt.new vs V0: comparativo completo com preços e testes
• Como criar um site com IA: ferramentas de vibe coding na prática
• V0 da Vercel: tutorial completo
• No-code: o guia para criar sem programar
• Melhores IDEs com IA em 2026
• O que é SaaS: guia completo