Quando um app Lovable precisa de verificação no Google OAuth
Nem todo app que conecta uma conta Google precisa passar pelo mesmo processo. Segundo o guia oficial da Lovable, você pode desenvolver e testar um app externo com um conjunto limitado de usuários de teste antes de pedir revisão. Apps usados apenas dentro de uma única organização Google Workspace também podem ser configurados como internos, o que muda os requisitos.
O ponto que define o nível de revisão são principalmente os scopes pedidos. Eles dizem quais dados e ações seu app quer acessar. No Google Cloud, esses scopes podem ser classificados como não sensíveis, sensíveis ou restritos.
Scopes não sensíveis
Permissões básicas de identidade, como nome, e-mail e perfil, normalmente não exigem verificação de acesso a dados. Ainda assim, você pode precisar concluir a verificação da marca para exibir nome e identidade visual de forma pública na tela de consentimento.
Scopes sensíveis
Permissões que expõem dados privados ou permitem agir sobre eles entram em um nível mais rigoroso. Ler eventos do Google Calendar é um exemplo. Nesse caso, o Google pode revisar por que seu produto precisa daquela permissão e onde essa função aparece para o usuário.
Scopes restritos
Permissões amplas, como acesso de leitura a Gmail ou Drive, podem ser classificadas como restritas. Além da verificação, esse nível pode envolver avaliação de segurança adicional e obrigações recorrentes. Por isso, pedir Drive ou Gmail apenas por precaução pode aumentar bastante a complexidade de lançamento.
A responsabilidade da Lovable e a responsabilidade de quem criou o app
Nos App User Connectors, cada pessoa conecta a própria conta e a Lovable mantém as credenciais no gateway de conectores. O app gerado não precisa receber diretamente a credencial do provedor. As chamadas continuam respeitando a identidade e as permissões da pessoa conectada.
Isso não elimina a responsabilidade do produto. Se seu app armazena, registra, compartilha ou processa os dados retornados pelo Google, você continua responsável por controle de acesso, retenção, exclusão e transparência sobre o uso dessas informações.
Passo a passo para preparar a verificação OAuth de um app Lovable
1. Defina a função que o usuário realmente vai usar
Antes de abrir o Google Cloud Console, descreva a ação do produto em linguagem simples. Exemplo: o usuário conecta o Google Calendar para que o app verifique horários disponíveis e crie agendamentos. Essa definição será a base para escolher scopes, explicar a finalidade no consentimento e gravar a demonstração para o revisor.
- O que o usuário consegue fazer
- Qual produto Google fornece os dados
- Se o app apenas lê ou também cria, altera e exclui informações
- Por que um scope mais restrito não atenderia a função
2. Escolha os menores scopes possíveis
Use o princípio de menor privilégio. Se o app só precisa saber se alguém está livre em determinado horário, um scope de disponibilidade pode ser suficiente. Se precisa criar ou editar eventos, você pode precisar de um scope de eventos. Não solicite um conjunto mais amplo só para deixar opções abertas no futuro.
Para cada scope sensível ou restrito, esteja pronto para explicar exatamente o que ele permite, onde a função aparece no app e por que um acesso menor impediria aquela experiência.
3. Configure e teste o OAuth de ponta a ponta
Antes de enviar para revisão, o fluxo precisa funcionar como será mostrado ao Google: APIs ativadas, scopes configurados, tela de consentimento coerente, cliente OAuth correto e redirect URI configurado conforme a integração usada pela Lovable. Um usuário de teste deve conseguir conectar a conta e usar a função completa.
4. Publique homepage e política de privacidade
A homepage deve estar em um domínio que você controla, abrir sem exigir login e explicar claramente o que o produto faz. A política de privacidade deve estar nesse mesmo domínio e informar como os dados do Google são acessados, usados, armazenados, compartilhados e excluídos.
Mantenha nome do app, descrição, domínio, identidade e finalidade consistentes entre o produto, a tela de consentimento, a homepage e a política. Divergências simples podem virar idas e voltas durante a revisão.
5. Grave o vídeo de demonstração
Para scopes sensíveis ou restritos, o processo pode pedir uma demonstração em vídeo. Mostre o fluxo completo, incluindo a tela de consentimento e a funcionalidade que justifica cada permissão. O revisor não deve precisar deduzir por que determinado acesso existe.
6. Publique o app para produção e envie para verificação
No Google Auth Platform, revise Audience, deixe o app no estado adequado para produção e use o fluxo de preparação e envio para verificação. Mantenha atualizados os e-mails dos proprietários e editores do projeto, porque pedidos adicionais do Google chegam por esses contatos.
7. Dê ao revisor um caminho funcional até a integração
Se a função fica atrás do login do seu próprio app, o Google pode pedir acesso para testá-la. Tenha preparado o endereço de login, instruções objetivas para chegar à conexão Google e, quando necessário, uma conta de teste ou autorização específica para o revisor.
