Voltar
Como restringir o escopo dos personal access tokens do Supabase

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

  1. Escopo de tokens do Supabase fica disponível de forma geral.

  2. Supabase anuncia o recurso no Supabase Select.

  3. 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

Avalie este artigo:
Categoria
CEVIU DevOps
Publicado
28 de outubro de 2026
Editoria
CEVIU DevOps

Quer receber mais sobre CEVIU DevOps?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser