Tela de consentimento do OAuth do Google: Configuração, Correções E por que não está aparecendo (2026)
A tela de consentimento do Google OAuth mudou em 2024. Ela agora está em Plataforma de Autenticação do Google no Cloud Console - não onde você costumava encontrar. Este guia mostra exatamente onde ir, como configurá-lo passo a passo e como corrigir os problemas mais comuns (inclusive quando ele se recusa a aparecer).
Onde fica? Desde 2024, a tela de consentimento do Google OAuth está localizada em APIs e Serviços > Plataforma de Autenticação do Google no Cloud Console - não no antigo item de menu "Tela de consentimento do OAuth". As configurações agora estão divididas em três guias: Marca (nome do aplicativo, logotipo, domínios), Público (Tipo de usuário Interno/Externo, usuários de teste), e Clientes (IDs de cliente OAuth). Se o menu não aparecer de forma alguma, seu projeto ainda não habilitou nenhuma API compatível com OAuth, ou sua conta não tem a função de Proprietário ou Editor.
Onde fica a tela de consentimento do OAuth em 2026?
Se você seguiu um tutorial escrito antes de 2024 e não encontra "Tela de consentimento do OAuth" na barra lateral esquerda, você não está imaginando coisas. O Google renomeou e reestruturou a seção inteira. Agora, vive sob um novo nome: Plataforma de Autenticação do Google. Este é o motivo mais comum pelo.
Etapa 1: Ir console.cloud.google.com e certifique-se de que o projeto correto esteja selecionado no seletor de projetos superior. Muitos problemas de "não exibição" são simplesmente causados por estar no projeto errado.
Etapa 2: Na barra lateral esquerda, clique em APIs e Serviços.
Etapa 3: Procurar Plataforma de Autenticação do Google no sub-menu (anteriormente chamado de "Tela de consentimento do OAuth"). Se você o vir, clique nele. Se não, consulte a seção de solução de problemas abaixo.
Passo 4: Você pousará no painel da Plataforma de Autenticação do Google. As três abas - Marca, Públicoe Clientes - substitua o formulário antigo da tela de consentimento de página única.
A guia "Público" na Plataforma de Autenticação do Google (anteriormente "Tela de consentimento do OAuth") - é aqui que você escolhe o tipo de usuário Interno ou Externo e gerencia usuários de teste.
A tela de consentimento do OAuth não aparece ou fica redirecionando: como resolver isso
A tela de consentimento de OAuth do Google pode falhar em aparecer ou se comportar inesperadamente por vários motivos distintos. Abaixo está cada padrão de erro com sua causa exata e a correção - formatado para ser o mais rápido possível de escanear.
A interface do usuário do Google Cloud Console mudou em 2024. O antigo item de menu "Tela de consentimento do OAuth" foi renomeado para ""Google Auth Platform"". Tutoriais mais antigos ainda fazem referência ao nome antigo.
Na barra lateral esquerda, em APIs e Serviços, role a tela até ver ""Google Auth Platform"". Se você ainda não estiver vendo, talvez seja necessário habilitar pelo menos uma API do Google no seu projeto primeiro (essa seção só aparece depois que uma API compatível com OAuth é habilitada).
Sua Conta do Google não tem o Função de Proprietário ou Editor no IAM no projeto. As contas com função de visualizador não podem editar as configurações da tela de consentimento.
Peça ao responsável pelo projeto para lhe conceder o Editor função (ou superior) por meio de IAM e Admin > IAM. Se você mesmo criou o projeto, verifique se está conectado com a conta do Google correta — às vezes, o seletor de projetos exibe projetos aos quais você tem acesso somente para leitura.
Você não selecionou um tipo de usuário (Interno vs. Externo) ainda. Na nova interface do usuário, o botão "Começar" na página de visão geral da Google Auth Platform espera que você conclua primeiro a etapa “Público-alvo”.
Na página de visão geral da Google Auth Platform, clique em ""Comece agora"" Se for solicitado, acesse o Guia "Público" e selecione “Interno” ou “Externo”. Assim que um tipo de usuário for salvo, o formulário completo de configuração de branding ficará disponível.
Seu aplicativo está em Status do teste (ou o status de publicação é "Em teste") e você está solicitando escopos confidenciais ou restritos. O Google exibe a tela intermediária de "aplicativo não verificado" antes da tela de consentimento propriamente dita.
Para desenvolvimento: adicione o e-mail do usuário de teste à sua lista de usuários de teste (Guia "Público"). Para produção: envie seu aplicativo para verificação OAuth do Google. Os usuários listados como usuários de teste ainda verão um aviso, mas poderão prosseguir clicando em "Avançado > Ir para [Nome do aplicativo]". O aviso desaparecerá assim que seu aplicativo for verificado e publicado.
Este é o comportamento esperado. Uma vez que um usuário concede consentimento, o Google se lembra da concessão e pula a tela em logins subsequentes. A tela de consentimento só reaparece se o usuário revogar o acesso ou se você solicitar novos escopos.
Para forçar a reexibição para teste, adicione consentimento para os parâmetros da sua URL de autorização. Em produção, use apenas consentimento na primeira chamada de autorização (para receber o token_de_atualização) - não em todos os logins.
acesso_negado erro em vez disso. Aplicativos internos são restritos a usuários dentro da sua organização do Google Workspace por design. Alterne para Externo se precisar dar suporte a usuários que não utilizam o Workspace.A chave OAuth pré-verificada da Unipile remove esses cenários de erro da sua configuração - nenhuma configuração de tela de consentimento da sua parte, como um intermediário técnico independente agindo em nome de cada usuário autenticado.
Como configurar a tela de consentimento do OAuth passo a passo
Esta seção cobre a configuração completa da tela de consentimento - a parte que você precisa completar após criar um projeto do Google Cloud e ativar uma API do Google. Se você ainda não realizou essas etapas, consulte o Guia completo do Google OAuth que cobre a criação de projetos e ativação de API primeiro.
Na Guia "Público", a primeira decisão é se seu app atende usuários dentro da sua organização do Google Workspace ou a qualquer usuário com uma conta do Google:
- Interno: apenas usuários dentro da sua organização do Google Workspace. Nenhuma verificação necessária. Ideal para ferramentas internas, painéis administrativos ou aplicativos empresariais usados apenas por seus próprios funcionários. Não disponível se o seu.
- Externo qualquer titular de conta Google. Os aplicativos começam em modo "Teste" com um limite de 100 usuários. Escopos sensíveis ou restritos exigem o processo de verificação do Google antes que o aplicativo possa ser publicado para todos os usuários.
Aba Público: escolha Interno (apenas do Workspace) ou Externo (qualquer conta Google). Essa decisão afeta seus requisitos de verificação.
Dica: você pode mudar de Interno para Externo mais tarde, mas não pode mudar de Externo de volta para Interno depois que os usuários autorizarem seu aplicativo. Escolha com cuidado.
Na Aba de Marca, preencha os seguintes campos. Estes são os que os usuários veem na tela de consentimento do Google OAuth ao autorizarem seu aplicativo:
- Nome do aplicativo: o nome exibido em destaque no topo da tela de consentimento. Use o nome do seu produto, não um identificador técnico.
- E-mail de suporte ao usuário: exibido na tela de consentimento como um contato para usuários que tiverem dúvidas sobre a solicitação de acesso do seu app. Use um alias monitorado ou lista de distribuição – não um e-mail pessoal.
- Logo do aplicativo: Um PNG ou JPG quadrado, com no mínimo 120x120px. Aparece na tela de consentimento e na lista de aplicativos autorizados da Conta Google. Opcional, mas altamente recomendado para a confiança do usuário.
Aba "Branding" - Informações do aplicativo: preencha o nome do aplicativo, o logotipo e o e-mail de suporte exatamente como você deseja que eles sejam exibidos aos usuários na tela de consentimento.
Ainda na Aba de Marca, a seção Domínio do Aplicativo requer os seguintes links:
- URL da página inicial do aplicativo: a página inicial pública do seu aplicativo ou produto. Deve ser um URL ativo e acessível (não uma página de login).
- Link para a Política de Privacidade: necessário para todos os aplicativos externos que solicitam permissões além do login básico. Deve mencionar explicitamente as permissões do Google solicitadas e como os dados são usados. A equipe de verificação do Google verifica isso cuidadosamente - uma política de privacidade ausente ou vaga é o motivo mais comum de rejeição.
- Link para os Termos de Serviço: opcional, mas recomendado para aplicativos em produção.
Domínio do App: forneça URLs de páginas ao vivo para sua página inicial, política de privacidade e termos de serviço. Todos os URLs devem ser acessíveis publicamente antes do envio para verificação.
O Domínios Autorizados seção (abaixo de Domínio do App) controla quais domínios podem ser usados em seus URIs de redirecionamento OAuth e nos links de domínio do app acima. Adicione o domínio raiz do seu aplicativo (ex:. yourapp.com).
Domínios autorizados: adicione seu domínio raiz. Somente URIs de redirecionamento e URLs de aplicativos deste domínio serão aceitos pelo Google.
Dica: domínios autorizados e URIs de redirecionamento (definidos na aba Clientes) devem ser consistentes. Se sua URI de redirecionamento for https://app.yourapp.com/callback, você precisa autorizar yourapp.com aqui, não app.yourapp.com.
Também no Aba de Marca, forneça um e-mail de contato do desenvolvedor. Este é o endereço que o Google usa para enviar:
- Atualizações de status de verificação (aprovação, rejeição ou solicitações de esclarecimento)
- Avisos de conformidade com a política
- Notificações sobre alterações no status OAuth do seu aplicativo
Contato do desenvolvedor: use uma lista de distribuição monitorada. E-mails críticos de verificação do Google podem ser filtrados como spam - verifique a pasta de spam durante sua janela de revisão.
Importante: use uma lista de distribuição ou caixa de entrada compartilhada, não um e-mail pessoal. A equipe de verificação do Google pode enviar e-mails durante o horário comercial em um fuso horário diferente. Se você perder a janela de resposta, sua verificação poderá ser atrasada em semanas.
Os escopos definem quais dados seu aplicativo pode acessar em nome do usuário. Na nova interface do usuário da Plataforma de Autenticação do Google, os escopos podem ser configurados por cliente OAuth (em Aba Clientes > selecionar um cliente > Escopos). Clique em "Adicionar ou Remover Escopos" para abrir o seletor de escopo.
Categorias de escopo que afetam seu caminho de verificação:
- Escopos não sensíveis (ex.
openid,e-mail,perfil): login básico apenas. Nenhuma verificação necessária. O aplicativo é publicado imediatamente. - Escopos sensíveis (ex.
gmail.somente leitura,gmail.enviar,gmail.marcadores): exigir uma avaliação de segurança do Google (verificação OAuth). O app permanece em modo de teste até ser verificado. - Escopos restritos (ex.
mail.google.com,gmail.modificar): requer OAuth do Google E uma auditoria de segurança CASA Nível 2. Leva significativamente mais tempo.
Seletor de escopo: escolha os escopos mínimos que seu aplicativo realmente precisa. Cada escopo sensível ou restrito adiciona requisitos de verificação. Planeje isso antes de construir.
Para uma referência completa dos escopos específicos do Gmail, quais APIs cada um desbloqueia e como solicitá-los em sua URL de autorização, consulte a Guia de Escopos da API do Gmail.
Princípio do menor privilégio: solicite apenas os escopos que seu aplicativo usa atualmente. Adicionar um escopo restrito após o lançamento significa reiniciar todo o processo de verificação, incluindo uma nova auditoria CASA Nível 2.
Na Guia "Público", o Usuários de teste seção permite que você adicione e-mails da conta Google que podem autorizar seu aplicativo enquanto ele está em Status do teste.
Regras principais sobre o limite de usuários de teste:
- Usuários de teste no máximo 100 pode ser adicionado a um aplicativo externo em status de teste. Este é um limite rigoroso do Google - você não pode aumentá-lo sem publicar seu aplicativo.
- Usuários de teste veem a tela de aviso "aplicativo não verificado", mas ainda podem autorizar seu aplicativo clicando para ignorar o aviso.
- Tokens de acesso para usuários de teste em modo de teste expiram após 7 dias. Os usuários devem autorizar novamente quando o token expirar.
- Uma vez que você submeta para verificação e o Google aprove seu aplicativo, o limite de 100 usuários é removido e a expiração de 7 dias desaparece.
Se precisar de mais de 100 usuários antes da verificação: a única opção é submeter o seu aplicativo para verificação do Google. Não há uma solução alternativa dentro dos sistemas do Google. Alternativamente, considere se a chave OAuth pré-verificada da Unipile (seção seguinte) pode gerenciar o fluxo OAuth para você, eliminando tanto o limite quanto o cronograma de verificação.
Quer pular todo este processo de configuração da tela de consentimento do OAuth?
Use a chave OAuth verificada da Unipile em vez disso - sem configuração de tela de consentimento, sem limite de 100 usuários, sem espera de verificação.
Interno vs. Externo: qual escolher?
A escolha "Interno" vs. "Externo" na tela de consentimento do Google OAuth é uma das decisões mais importantes na sua configuração. Ela determina seu caminho de verificação, sua base de usuários e se você enfrentará um limite de 100 usuários durante o desenvolvimento. Aqui está o quadro completo.
Pule a decisão Interno vs. Externo completamente
Com a chave OAuth pré-verificada da Unipile.
Após a tela de consentimento: verificação e CASA
A conclusão da configuração da tela de permissão do Google OAuth não é o fim do processo para aplicativos externos que solicitam escopos sensíveis ou restritos. O que vem a seguir depende de quais escopos você escolheu. Aqui está a versão resumida - o guia completo de verificação e CASA está em Hub do Google OAuth.
Logo após configurar a tela de consentimento do OAuth, seu aplicativo externo estará em Status do teste. Somente os usuários que você adicionar à lista de usuários de teste (até 100) podem autorizar seu aplicativo. Isso é bom para desenvolvimento e testes iniciais.
Quando estiver pronto para abrir seu aplicativo para mais usuários, clique em "Prepare-se para a Verificação" (ou "Enviar para verificação") na visão geral da Plataforma de Autenticação do Google. O Google revisa a política de privacidade do seu app, domínios autorizados, escopos solicitados e como seu app usa os dados. O tempo de revisão varia — geralmente 2 a 6 semanas, às vezes mais para escopos restritos.
Se o seu aplicativo solicita escopos restritos (como mail.google.com ou gmail.modificar), o Google também exige um Auditoria de segurança CASA Nível 2 por um avaliador terceirizado aprovado. Isso envolve uma revisão da postura de segurança do seu aplicativo, manuseio de dados e controles de acesso.
Após a verificação, seu aplicativo é publicado. A tela de aviso "aplicativo não verificado" desaparece. O limite de 100 usuários é removido. A expiração de 7 dias do token para usuários de teste deixa de existir. Os usuários veem sua tela de consentimento com sua marca, sem avisos.
Para uma visão mais ampla de como o Google OAuth se encaixa na arquitetura de API de e-mail - incluindo acesso unificado a provedores em Gmail, Outlook e IMAP - veja a Guia da API de E-mail.
A Unipile já concluiu a auditoria CASA Tier 2 para sua integração com o Google OAuth. Isso significa que, quando você usa a Unipile como um intermediário técnico independente, a agir em nome de cada usuário autenticado, você não precisa passar pelo processo da CASA. Veja a Hub completo do Google OAuth para os detalhes sobre o caminho de certificação da Unipile e como funciona o fluxo de trabalho de POC / certificar mais tarde / alternar.
Pule a configuração da tela de consentimento completamente
Se seu produto precisa acessar dados do Gmail ou Google Agenda dos usuários, você pode optar por configurar a tela de consentimento do Google OAuth sozinho – ou você pode usar Unipile como um intermediário técnico independente, a agir em nome de cada usuário autenticado, com uma chave OAuth pré-verificada que já possui certificação CASA Nível 2. Isso não é uma solução alternativa para a revisão de segurança do Google. A Unipile completou essa revisão para você - esse é o produto.
Unipile não é afiliada, endossada ou patrocinada pelo Google. A Unipile opera como um intermediário técnico independente entre seu aplicativo e a infraestrutura de OAuth do Google.
Conecte as contas do Google dos seus usuários por meio da integração OAuth verificada do Unipile. Seus usuários autorizam uma única vez — o Unipile cuida do resto, atuando como um intermediário técnico independente, em nome de cada usuário autenticado.
Tela de Consentimento do OAuth do Google - FAQ
As perguntas mais comuns sobre configuração, solução de problemas e navegação na tela de consentimento do Google OAuth em 2026.
Existem cinco razões comuns: (1) Você está procurando o menu antigo "Tela de consentimento do OAuth" - ele foi renomeado para ""Google Auth Platform"" em 2024. (2) Você está no projeto errado - verifique o seletor de projetos no topo. (3) Sua conta não possui a função IAM de Proprietário ou Editor. (4) Nenhuma API compatível com OAuth foi habilitada no projeto ainda - a seção da Plataforma de Autenticação do Google só aparece uma vez que uma API é ativada. (5) Seu aplicativo está configurado como Interno, mas você está testando com uma conta Google externa - Apps internos bloqueiam todos os usuários que não pertencem ao Workspace por padrão. Para correções detalhadas, consulte a seção de solução de problemas acima.
Desde 2024, navegue até APIs e Serviços > Plataforma de Autenticação do Google. O item de menu "Tela de consentimento do OAuth" foi substituído pela Plataforma de autenticação do Google, que organiza as configurações em três abas: Marca (nome do aplicativo, logotipo, domínios), Público (Tipo de usuário Interno/Externo, usuários de teste), e Clientes (IDs de cliente OAuth e URIs de redirecionamento). Essa reestruturação da interface do usuário é a principal causa da pesquisa "não exibindo a tela de consentimento do Google OAuth" em 2026.
Mais sobre isso em nosso Guia completo do Google OAuth Playground.Interno: todos os usuários estão na sua organização do Google Workspace, sem necessidade de verificação, sem limite de usuários de teste, sem aviso de não verificado. Ideal para ferramentas internas. Requer uma conta do Workspace (não Gmail pessoal).
Externo: qualquer titular de conta Google pode usar seu aplicativo. Inicia no modo de teste (limite de 100 usuários). Escopos sensíveis exigem verificação do Google (2-6 semanas). Escopos restritos exigem adicionalmente o Nível 2 do CASA. Escolha Externo para qualquer aplicativo público ou voltado para o cliente.
O limite máximo é 100 usuários de teste para Aplicativos externos em status de Teste. Este limite é definido pelo Google e não pode ser contornado. Testadores ainda podem autorizar seu aplicativo, mas verão uma tela de aviso primeiro. Seus tokens expiram após 7 dias (em vez do tempo de vida normal do token de atualização). Para remover o limite, envie seu aplicativo para verificação OAuth do Google. Uma vez publicado, não há limite de usuários.
Depende da sua configuração: Aplicativos internos nunca precisa de verificação. Aplicativos externos usando apenas escopos básicos (openid, e-mail, perfil) podem publicar sem verificação. Aplicativos externos solicitando escopos sensíveis gostar de gmail.enviar, gmail.somente leitura) deve passar pela verificação OAuth do Google antes de remover o limite de 100 usuários. Aplicativos externos solicitando escopos restritos gostar de mail.google.com) exigem adicionalmente uma auditoria de segurança CASA Nível 2 - além da verificação padrão. Veja o Guia de Escopos da API do Gmail para a classificação de escopo completo.
Você não pode pular a tela de consentimento do Google na própria infraestrutura do Google – é uma etapa obrigatória para qualquer fluxo OAuth 2.0. No entanto, você pode evitar configurá-la e verificá-la você mesmo usando Chave OAuth pré-verificada da Unipile. A Unipile atua como intermediador técnico independente, em nome de cada usuário autenticado, com verificação do Google e certificação CASA Tier 2 já concluídas. Isso não é uma solução alternativa de segurança - O Unipile passou pelo processo completo de revisão do Google. Seus usuários ainda veem uma tela de consentimento (a tela verificada do Unipile), você só não precisa criar e verificar a sua própria.
Descubra integração com a API do Gmail pronta para produção.Ainda tem dúvidas sobre a configuração do Google OAuth? Nossa equipe está aqui para ajudar.