Reduza escopos OAuth para reduzir atrito na revisão de apps

Por que as revisões de apps travam por causa de escopos OAuth

As revisões de OAuth atrasam por um motivo simples: as permissões que você solicita não parecem necessárias com base no que o revisor consegue ver e testar.

Os revisores frequentemente começam pela lista de escopos e perguntam: "Se eu aprovar isso, o que o app pode ler ou alterar, e onde isso é usado no produto?" Se eles não conseguem mapear rapidamente os escopos para telas e ações, pausam a revisão e pedem provas.

Uma lista longa de escopos é um sinal de alerta porque aumenta o risco para o usuário e pode parecer que o app está coletando dados "só por precaução." Escopos não usados são ainda pior. Mesmo que você nunca chame a API, o revisor só vê o acesso potencial.

Notas típicas de rejeição soam como: "Não está claro por que essa permissão é necessária", "Escopos solicitados são muito amplos para a funcionalidade descrita" ou "Não é possível mapear escopos para recursos." Uma causa comum é código inicial de template ou gerado por IA que pede permissões extras (por exemplo, um fluxo básico de "Sign in with Google" que também pede para modificar arquivos ou ler contatos).

A maneira mais rápida de destravar é reduzir os escopos ao mínimo e explicar cada permissão restante em linguagem simples que o revisor possa verificar.

Escopos em linguagem simples (e por que o privilégio mínimo importa)

Um escopo OAuth é uma permissão que seu app solicita quando um usuário conecta a conta. Cada escopo diz ao provedor o que seu app está autorizado a fazer, como ler um perfil ou acessar eventos do calendário.

Privilégio mínimo é a regra que os revisores querem ver você seguir: solicite o menor conjunto de permissões necessário para o recurso que o usuário espera. Se você só precisa exibir eventos do calendário, pedir acesso de leitura e escrita ao calendário inteiro é difícil de justificar.

Escopos amplos levantam preocupações de segurança e privacidade porque aumentam o que pode ser exposto se algo der errado (um bug, um token vazado ou um atacante). Eles também prejudicam conversões: usuários decidem em segundos na tela de consentimento, e "acesso demais" é abandonado.

Passo 1: Faça o inventário de cada escopo que seu app solicita

Antes de reduzir qualquer coisa, obtenha uma lista completa do que seu app solicita hoje. Muitas equipes deixam passar escopos que ainda são solicitados em algum lugar, mesmo que a UI e a documentação digam o contrário.

Os escopos geralmente aparecem em três lugares:

• Seu código (requisição OAuth, chamadas de SDK)
• Sua configuração/ambiente (env vars, JSON/config mobile)
• O console do provedor (permissões ativadas durante testes)

Crie uma tabela de inventário simples para que sua visão interna corresponda ao que os revisores verão.

Enquanto preenche, fique atento a surpresas comuns: o mesmo escopo solicitado duas vezes (código mais defaults de biblioteca), escopos legados de experimentos antigos e escopos que existem só no console mas não no código.

Faça uma checagem rápida assinando com um usuário de teste e anotando o texto da tela de consentimento. Se você vir permissões que não reconhece, elas pertencem à tabela.

Passo 2: Mapeie cada escopo para um recurso visível ao usuário

Para os revisores, um escopo não é "algo que o app precisa." Cada escopo deve mapear para um recurso que o usuário pode ver e usar.

Para cada escopo, responda duas perguntas em linguagem simples:

1. Qual recurso para de funcionar se esse escopo for removido?
2. Qual ação do usuário aciona esse recurso?

Isso transforma "ler calendário" em um fluxo concreto e testável como: "O usuário clica em Import events, seleciona um intervalo de datas e mostramos as próximas reuniões no painel."

Para documentação, mantenha simples:

• Nome do recurso (as palavras usadas na sua UI)
• Gatilho (o clique ou passo)
• Dados usados (leitura/escrita)
• Essencial vs opcional
• Quando solicitar (no cadastro vs só quando necessário)

Seja rigoroso sobre essencial vs opcional. Se um escopo só suporta um recurso adicional, não o solicite no primeiro login. Peça apenas quando o usuário tentar usar esse recurso. Revisores gostam disso porque o prompt de consentimento corresponde à intenção do usuário.

Exemplo: se seu app tem Login mais um recurso opcional Sync contacts, o login deve usar escopos básicos de identidade. Escopos de contatos devem aparecer só quando o usuário clicar em Sync contacts pela primeira vez, com uma explicação de uma frase.

Passo 3: Substitua escopos amplos por alternativas mais estreitas

Escopos amplos são uma das formas mais rápidas de atrasar uma revisão de app OAuth. Se você quer manter os recursos mas reduzir risco, substitua permissões "tudo" pelo escopo mais estreito que ainda suporte o que o usuário realmente faz.

Comece com o básico:

• Prefira somente leitura ao invés de leitura-escrita quando puder.
• Prefira um escopo específico do produto ao invés de um escopo de suíte inteira.
• Para arquivos, prefira app-folder ou arquivos escolhidos pelo usuário ao invés de acesso full-drive.

A autorização incremental também ajuda. Peça o mínimo no primeiro login (geralmente só identidade), depois solicite escopos adicionais somente quando o usuário acionar o recurso que os requer.

Se seu app só precisa autenticar o usuário e mostrar o nome, solicitar storage, email ou acesso ao calendário é difícil de defender. Mantenha só identidade e peça escopos de dados somente no momento em que o usuário habilitar o recurso.

Passo 4: Remova escopos não usados com segurança

Quando tiver confiança de que um escopo não é necessário, remova-o de forma controlada. É aqui que as equipes ficam nervosas, porque o risco é quebrar um fluxo raramente usado. Feito com cuidado, o ganho é grande: menos permissões, menos perguntas do revisor.

Primeiro, comprove que ele está realmente sem uso. Não confie na memória. Busque na base de código por endpoints que exigem o escopo e verifique as configs onde os escopos são montados.

Também verifique usos ocultos que podem não aparecer na UI principal: workers em background, jobs agendados, páginas só para admin e handlers de webhook.

Fluxo seguro de remoção

Use uma sequência repetível para poder voltar rapidamente:

• Identifique os endpoints/ações ligados ao escopo e confirme que não estão sendo chamados.
• Verifique caminhos não óbvios (cron jobs, filas, webhooks, ferramentas internas).
• Remova o escopo da requisição de auth e da configuração de consentimento.
• Faça deploy em staging e execute os fluxos reais de usuário.
• Monitore erros por várias horas (ou um dia) antes de remover o próximo escopo.

Recursos mortos são uma razão comum para escopos persistirem. Se você antes tinha "import contacts" ou "sync calendar" e agora está desligado, a permissão pode ainda estar sendo solicitada embora nada a use.

Mantenha um pequeno log de remoção

Revisores frequentemente perguntam por que uma permissão mudou. Mantenha um registro curto: qual escopo foi removido, o que ele suportava (se suportava algo), como você confirmou que não era usado e a data.

Torne suas explicações de permissão fáceis de verificar para revisores

Os revisores não estão tentando adivinhar sua intenção. Eles querem confirmar que cada permissão corresponde a um recurso real, e que os usuários recebem a mesma explicação em todos os lugares: tela de consentimento, UI do app e texto de política.

Atualize o texto da tela de consentimento para descrever o que o app faz hoje, não o que você planejou meses atrás. Se você removeu um recurso, remova também a redação. Texto desconectado é uma maneira fácil de gerar perguntas de acompanhamento.

Escreva "uma permissão, um propósito"

Para cada escopo restante, escreva uma frase que responda:

• Quais dados?
• Por que você precisa deles?
• Quando você os acessa?

Exemplo: "Ler seus eventos do Google Calendar para que possamos mostrar suas próximas reuniões no painel quando você conectar sua conta."

Evite linhas vagas como "para melhorar sua experiência" ou "para automação." Elas não dizem ao revisor o que você toca, quando ou por quê.

Facilite a verificação mantendo a nomenclatura consistente:

• Use os mesmos nomes de recursos na UI e no texto de consentimento.
• Dispare solicitações no momento em que o recurso é usado (não no primeiro login).
• Adicione uma nota curta no app perto do botão de conectar que repete a razão.
• Se o acesso for opcional, diga isso e mostre que o app continua funcionando sem ele.

Teste após reduzir: prove que nada quebrou

Depois de reduzir escopos, o app pode continuar funcionando na sua conta usual porque você concedeu acesso amplo no passado. Teste como um usuário novo e como um revisor.

Use uma conta de teste totalmente nova (ou workspace limpo) que nunca autorizou seu app. Execute o fluxo completo de login e setup do zero.

Depois teste os casos de borda que interessam aos revisores:

• Revogue o acesso do app e tente novamente (deve refazer a autenticação corretamente).
• Expire tokens ou invalide refresh tokens (deve se recuperar sem loops).
• Conceda apenas os escopos mínimos (sem crashes, sem telas em branco).
• Negue um escopo opcional (o recurso deve desativar com uma mensagem clara).
• Use um segundo dispositivo ou sessão de navegador (para pegar problemas de redirect/state).

Se um escopo é verdadeiramente opcional, o recurso deve degradar graciosamente. Por exemplo: mostrar "Conecte seu calendário para ativar lembretes" em vez de falhar quando a tela de calendário carregar.

Após qualquer alteração de escopo, repita os passos de verificação do provedor usando as mesmas instruções que você planeja submeter: setup claro, cliques exatos e o que o revisor deve ver em cada passo.

Erros comuns que geram rejeições ou longos idas e vindas

A maioria dos atrasos não é sobre seu produto. Acontecem porque o revisor não consegue associar cada permissão a um recurso real, em telas reais, com o menor acesso necessário.

Dois padrões causam mais problemas:

• Acesso de escrita quando o recurso é só leitura (por exemplo, pedir permissão de edição quando você só exibe dados).
• Solicitar tudo no primeiro login, mesmo para recursos opcionais.

Explicações vagas também atrasam revisões. "Melhorar a experiência" ou "para funcionalidade" não dizem ao revisor quais dados você toca, quando ou por quê.

Outras incompatibilidades comuns incluem escopos antigos deixados por protótipos, texto de consentimento que não bate com o comportamento, instruções do revisor que referenciam recursos ausentes na build, e um escopo genérico usado quando um escopo mais restrito serviria.

Checklist rápido antes de reenviar para revisão

Antes de reenviar, certifique-se de que cada permissão conte uma história simples e verificável.

• Para cada escopo, escreva o nome exato do recurso que ele alimenta e um passo que um revisor pode seguir para vê-lo na UI.
• Confirme que está usando o escopo mais restrito que suporta o recurso.
• Garanta que a redação da tela de consentimento corresponda ao comportamento real ("ler" vs "gerenciar").
• Remova escopos legados de protótipos e boilerplate.
• Re-teste fim a fim com uma conta limpa (sem tokens em cache).

Um hábito prático: mantenha uma nota de "justificativa de permissão" de uma frase por escopo nos docs internos. Quando um revisor perguntar "por que você precisa disso?" você pode responder rápido e apontar uma tela específica.

Exemplo: reduzir escopos para destravar uma revisão parada

Um fundador tinha um protótipo gerado por IA que se conectava ao Google Drive. O app pedia acesso total ao Drive porque o código template usava o escopo mais amplo por padrão. Na realidade, o único recurso do Drive era exportar um relatório em PDF e salvá-lo no Drive do usuário.

A solução foi reduzir escopos para corresponder àquela única ação. Substituímos a permissão de acesso total ao Drive por uma permissão mais estreita no estilo "criar arquivos apenas" e paramos de pedi-la durante o login. Em vez disso, a permissão do Drive era solicitada somente quando o usuário clicava em Export.

O que mudou no app

Três mudanças facilitaram para o revisor confirmar o comportamento:

• A permissão do Drive foi removida da tela de consentimento inicial.
• Um botão Export to Drive acionava um prompt de consentimento separado.
• As chamadas à API do Drive foram limitadas à criação do PDF, sem listar, ler, deletar ou modificar arquivos existentes.

A nota do revisor que funcionou

A re-submissão incluiu uma nota curta como:

"A permissão do Drive é solicitada somente quando um usuário clica em Export to Drive. Ela é usada para criar um novo arquivo PDF no Drive do usuário. O app não lê, lista, modifica ou deleta arquivos existentes. Para verificar: entre sem acesso ao Drive, abra Reports, clique em Export to Drive, complete o consentimento e confirme que um único novo PDF foi criado."

O feedback melhorou imediatamente: menos perguntas de acompanhamento, e a aprovação saiu de "presa por mais de uma semana" para "liberada em cerca de 2 dias."

Próximos passos se seu app foi gerado por IA ou a lista de escopos estiver bagunçada

Bases de código geradas por IA costumam solicitar mais permissões do que precisam. Ferramentas podem copiar escopos de exemplos, puxar defaults de SDK ou deixar recursos pela metade que ainda pedem acesso.

Se você não consegue apontar o arquivo/função exata que usa cada escopo, ou os revisores já fizeram perguntas que você não sabe responder com confiança, uma auditoria focada geralmente é mais rápida do que tentar adivinhar.

Se você está lidando com um protótipo gerado por IA de ferramentas como Lovable, Bolt, v0, Cursor ou Replit, FixMyMess (fixmymess.ai) ajuda equipes a diagnosticar o uso de escopos, remover permissões arriscadas ou não usadas e verificar que o app ainda funciona fim a fim antes de reenviar.