Supabase permite restringir o escopo dos personal access tokens
Aprofundamento CEVIU
Aprofundamento
Até agora, um personal access token do Supabase fazia tudo o que o dono da conta fazia, em todas as organizações e projetos. Pipeline de CI, script de deploy e agente de código recebiam o mesmo poder, mesmo quando precisavam só de uma tarefa de leitura. Agora o token pode ser limitado a organizações, projetos, permissões e data de expiração. A expiração pode ser customizada em até um ano.
Alguns detalhes operacionais importam. O token escopado começa com o prefixo sbp_fc e usa autenticação bearer padrão. Escopo e permissões ficam fixos na criação, então qualquer ajuste exige um token substituto. A permissão efetiva é sempre a interseção entre o token e o seu papel de usuário: se você perde acesso a um projeto, o token perde também. Uma requisição sem permissão recebe 403, e o campo missing_permissions diz o que faltou. No MCP, execute_sql com Database read só roda consultas de leitura, e apply_migration exige a permissão separada de Migrations read-write.
Há pegadinhas para CI. O fluxo de navegador do supabase login ainda cria token com acesso total, então o caminho é criar o token no Dashboard e passar com supabase login --token, ou definir SUPABASE_ACCESS_TOKEN, que sobrepõe tokens salvos localmente. Comandos de banco que usam SUPABASE_DB_PASSWORD ignoram as permissões do token. Se o workflow roda supabase link, o token precisa de leitura em Project Settings, API Keys e API Key Secrets. O preset Read-only inclui segredos como API keys, por isso a própria documentação sugere partir do No access. Tokens antigos seguem valendo até expirar ou serem apagados, marcados como Legacy.
Por que isso importa
Para quem opera pipelines, a leitura prática é trocar tokens de conta inteira por credenciais por job: um token de leitura para o agente, outro com escrita para o deploy, ambos com validade curta. Se um segredo vazar no log de CI, o estrago fica restrito a um projeto e a um conjunto de permissões. Vale auditar os tokens Legacy e checar onde SUPABASE_DB_PASSWORD contorna o modelo novo.
Linha do tempo
Escopo de tokens do Supabase fica disponível de forma geral.
Supabase anuncia o recurso no Supabase Select.
Supabase detalha como restringir o escopo dos personal access tokens por organização, projeto, permissão e expiração.
Perguntas frequentes
Meus tokens atuais do Supabase vão parar de funcionar?
Não. Não há data de descontinuação, e cada token existente funciona até expirar ou ser deletado. Os de acesso total aparecem com o selo Legacy no Dashboard, e a opção de criar um token legacy continua disponível.
Dá para alterar o escopo de um token depois de criado?
Não. Escopo e permissões ficam fixos na criação. Para mudar, é preciso criar um token substituto e trocá-lo nas integrações.
Como usar o token escopado no CI?
Crie o token no Dashboard e defina a variável SUPABASE_ACCESS_TOKEN, que sobrepõe tokens salvos localmente. Se o workflow usa supabase link, inclua leitura em Project Settings, API Keys e API Key Secrets.
O token pode ter mais permissão do que o meu usuário?
Não. Cada requisição avalia o escopo do token e o seu papel atual. Se você perde acesso a um recurso, o token também perde, e volta a funcionar se o acesso for restaurado.
Fontes
- supabase.comfonte original
- Categoria
- CEVIU DevOps
- Publicado
- 28 de outubro de 2026
- Editoria
- CEVIU DevOps

