O que é o Supabase Auth e como funcionam seus usuários e sessões?
Publicado em 2026-10-20 por frfrand
Supabase Auth explicado: login, registro, JWT, sesiones, refresh token, recuperación de cuenta y relación con las políticas RLS.
Supabase Auth é o serviço do Supabase que ajuda a registrar usuários, verificar a identidade deles e manter sessões dentro de um aplicativo. Permite implementar métodos como e-mail e senha, links mágicos e determinados provedores externos sem escrever todo o mecanismo de autenticação do zero.
Mas cuidado: autenticar não é o mesmo que autorizar. Saber quem é uma pessoa não significa que ela tenha permissão para consultar todos os dados do seu projeto.
O exemplo da biblioteca
Imagine uma biblioteca com cartões de sócio. Mostrar o cartão permite que o pessoal saiba quem você é, mas isso não significa que você possa abrir o armário de administração ou levar um livro reservado para outra pessoa.
Em um aplicativo ocorre algo parecido: o login identifica o usuário; as regras de autorização decidem a quais dados e operações ele pode acessar.
Supabase Auth fornece peças para a primeira parte e se integra com capacidades do PostgreSQL, como RLS, para apoiar a segunda.
O que acontece quando alguém faz login?
Em um fluxo habitual, o cliente envia credenciais a um serviço de autenticação. Se forem verificadas, ele pode receber dados de sessão e tokens que usará em requisições posteriores.
Supabase utiliza JWT, ou JSON Web Tokens, para representar certas informações de identidade e sessão. Um JWT assinado permite ao receptor comprovar sua validade seguindo as regras do sistema.
O token não deve ser confundido com uma senha nem com uma garantia de que qualquer solicitação está autorizada. Também é necessário validar seu emissor, vigência, assinatura e propriedades esperadas.
O que é um access token?
É uma credencial que o cliente utiliza durante um período limitado para demonstrar que dispõe de uma sessão válida.
Quando uma aplicação realiza uma requisição aos serviços do Supabase, as bibliotecas podem gerenciar o envio do token correspondente.
O servidor ou base utiliza essa identidade dentro de seus mecanismos de autorização. Por exemplo, uma política RLS pode permitir que a pessoa consulte somente suas próprias reservas.
E o refresh token?
Serve para solicitar novas credenciais de acesso sem pedir a senha ao usuário em cada operação.
A duração, renovação e revogação de sessões depende da configuração. Não convém copiar valores de um guia antigo sem revisar a documentação da versão atual.
Também é necessário decidir o que acontece ao encerrar sessão, alterar senha ou detectar um dispositivo comprometido.
Onde os tokens são guardados?
Depende da arquitetura. Uma aplicação de navegador, um app móvel e um backend tradicional não necessariamente devem gerenciar sessões da mesma maneira.
Salvar credenciais em locais acessíveis a JavaScript implica considerações contra ataques XSS. Usar cookies também exige estudar atributos, políticas de origem e proteção contra certas solicitações indesejadas.
O importante é escolher um padrão recomendado para o seu framework e compreender seus riscos, não mover tokens de um lugar para outro porque um tutorial disse que é «mais seguro».
O que é um link mágico?
Em vez de inserir uma senha tradicional, o usuário recebe um link de acesso enviado por e-mail. O sistema valida esse link sob condições definidas.
É conveniente, mas a segurança depende muito da conta de e-mail e de como os links são protegidos e expiram. Se alguém controlar o e-mail da pessoa, pode tentar aproveitar métodos de recuperação ou acesso.
O Supabase Auth substitui toda a lógica de usuários?
Não necessariamente. Pode gerenciar identidade e sessões, enquanto seu aplicativo mantém perfis, preferências, funções comerciais e outras tabelas.
Não é conveniente usar diretamente as tabelas internas do sistema de autenticação como se fossem seu modelo completo de negócio. Siga os mecanismos suportados para vincular identidades com dados do aplicativo.
Como o RLS intervém?
Quando uma solicitação chega com uma identidade verificada, o PostgreSQL pode aplicar políticas que limitem linhas visíveis ou modificáveis.
Uma política de leitura não protege automaticamente todas as operações. Também é preciso revisar permissões SQL e chaves privilegiadas. Em particular, nunca publique segredos administrativos no frontend.
Quando vale a pena usar o Supabase Auth?
É útil se o seu aplicativo já trabalha com o ecossistema Supabase e precisa de login, sessões e permissões de acesso a dados.
Se você tem um backend completo com um sistema de usuários consolidado, talvez seja melhor integrar esse sistema em vez de manter duas fontes de identidade desnecessariamente.
E no ArduMaker?
Se você hospeda um backend próprio ou bancos PostgreSQL em VPS da ArduMaker, pode implementar autenticação com ferramentas apropriadas para sua arquitetura. O Supabase Auth é uma opção externa diferente, não uma função que deva ser assumida como disponível por padrão em qualquer PostgreSQL.
Em resumo: o Supabase Auth resolve grande parte da autenticação; seu aplicativo ainda precisa de autorização, sessões seguras e design correto de permissões.
Fontes: Documentação do Supabase Auth · Sessões do Supabase · JWT no Supabase.