Obedeça às políticas do OAuth 2.0

Quando estiver tudo pronto para implantar a solução implementada além do ambiente de desenvolvimento para os usuários do app, talvez seja necessário tomar outras medidas para obedecer às políticas do OAuth 2.0 do Google. Neste guia, descrevemos como entrar em conformidade com os problemas mais comuns dos desenvolvedores encontrados quando você prepara seu app para produção. Isso ajuda você a alcançar o maior público-alvo possível com erros limitados.

Usar projetos separados para testes e produção

As políticas de OAuth do Google exigem projetos separados para teste e produção. Algumas políticas e requisitos se aplicam apenas a apps de produção. Talvez seja necessário criar e configurar um projeto separado que inclua clientes OAuth que correspondam à versão de produção do seu aplicativo disponível para todas as Contas do Google.

Os clientes OAuth do Google usados em produção fornecem um ambiente de coleta e armazenamento de dados mais estável, previsível e seguro do que clientes OAuth semelhantes que testam ou depuram o mesmo aplicativo. Seu projeto de produção pode ser enviado para verificação e, portanto, está sujeito a requisitos adicionais para escopos de API específicos, que podem incluir avaliações de segurança de terceiros.

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. Revise os clientes OAuth neste projeto que podem estar associados ao seu nível de teste. Se aplicável, crie clientes OAuth semelhantes para os clientes de produção dentro do seu projeto de produção.
  3. Ative as APIs em uso pelos seus clientes.
  4. Revise a configuração da tela de permissão do OAuth no novo projeto.

Os clientes OAuth do Google usados em produção não podem conter ambientes de teste, URIs de redirecionamento ou origens JavaScript disponíveis apenas para você ou para sua equipe de desenvolvimento. Veja alguns exemplos:

  • Os servidores de teste de desenvolvedores individuais
  • Testar ou pré-lançar versões do app

Manter uma lista de contatos relevantes para o projeto

Talvez o Google e as APIs individuais que você ativar possam entrar em contato com você para informar alterações nos serviços ou novas configurações necessárias para o projeto e os clientes dele. Revise as listagens do IAM do seu projeto para garantir que as pessoas relevantes na sua equipe tenham acesso para editar ou visualizar a configuração do seu projeto. Essas contas também podem receber e-mails sobre mudanças necessárias no projeto.

Um papel contém um conjunto de permissões que permitem executar ações específicas nos recursos do projeto. Os editores do projeto têm permissões para ações que modificam o estado, como a capacidade de fazer alterações na tela de consentimento OAuth do projeto. Os proprietários de projetos com todas as permissões de editor podem adicionar ou remover contas associadas ao projeto ou excluí-lo. Os proprietários de projetos também podem dar contexto sobre por que as informações de faturamento podem ser definidas. Os proprietários de projetos podem configurar informações de faturamento para um projeto que usa APIs pagas.

Os proprietários e os editores do projeto precisam estar atualizados. É possível adicionar várias contas relevantes ao projeto para garantir o acesso contínuo ao projeto e à manutenção relacionada. Enviaremos e-mails para essas contas quando houver notificações sobre seu projeto ou atualizações nos nossos serviços. Os administradores da organização do Google Cloud precisam garantir que um contato acessível esteja associado a cada projeto da organização. Se não tivermos dados de contato atualizados do seu projeto, você poderá perder mensagens importantes que exigem sua ação.

Representar sua identidade com precisão

Forneça um nome de app válido e, se quiser, um logotipo para mostrar aos usuários. Essas informações da marca precisam representar com precisão a identidade do aplicativo. As informações de marca do app são configuradas pelo OAuth Consent Screen page.

Para apps de produção, as informações de marca definidas na tela de consentimento do OAuth precisam ser verificadas antes de serem exibidas aos usuários. É mais provável que os usuários concedam acesso ao seu app depois que ele concluir a verificação da marca. As informações básicas do aplicativo, que incluem o nome, a página inicial, os Termos de Serviço e a Política de Privacidade do aplicativo, são exibidas aos usuários na tela de concessão, ao revisar as concessões existentes ou aos administradores do Google Workspace que avaliam o uso dos aplicativos pela organização.

O Google pode revogar ou suspender o acesso aos Serviços de API do Google e a outros produtos e serviços do Google para apps que deturpam a identidade ou tentam enganar os usuários.

Solicite apenas os escopos necessários

Durante o desenvolvimento do seu aplicativo, você pode ter usado um escopo de exemplo fornecido pela API para criar uma prova de conceito no aplicativo e saber mais sobre os recursos e a funcionalidade dessa API. Esses exemplos de escopo costumam solicitar mais informações do que a implementação final das necessidades do app, porque fornecem uma cobertura abrangente de todas as ações possíveis para uma API específica. Por exemplo, o escopo do exemplo pode solicitar permissões de leitura, gravação e exclusão, enquanto o aplicativo exige apenas permissões de leitura. Solicite permissões relevantes limitadas às informações necessárias para implementar seu aplicativo.

Revise a documentação de referência para os endpoints de API que seu app chama e observe os escopos necessários para acessar os dados relevantes de que o app precisa. Consulte os guias de autorização oferecidos pela API e descreva os escopos com mais detalhes para incluir o uso mais comum. Escolha o acesso mínimo a dados que o aplicativo precisa para potencializar os recursos relacionados.

Para mais informações sobre esse requisito, leia a seção Somente escopos de solicitação necessários das políticas do OAuth 2.0, além da seção Solicitar permissões relevantes da política de dados do usuário dos serviços da API do Google.

Enviar apps de produção que usam escopos confidenciais ou restritos para verificação

Alguns escopos são classificados como "quot;sensitive" ou "restricted" e não podem ser usados em apps de produção sem revisão. Insira todos os escopos usados pelo app de produção na configuração da tela de permissão OAuth. Se o app de produção usa escopos confidenciais ou restritos, é necessário enviar o uso desses escopos para verificação antes de incluir os escopos em uma solicitação de autorização.

Use apenas domínios que pertençam a você

O processo de verificação da tela de permissão OAuth do Google exige a verificação de todos os domínios associados à página inicial do seu projeto, a Política de Privacidade, os Termos de Serviço, os URIs de redirecionamento autorizados ou as origens do JavaScript autorizadas. Revise a lista de domínios em uso pelo app, resumidas na seção Domínios autorizados do editor da tela de permissão OAuth, e identifique os domínios que não são seus e que você não poderia verificar. Para verificar a propriedade dos domínios autorizados do seu projeto, use o Google Search Console. Use uma Conta do Google associada ao seu projeto API Console como proprietário ou editor.

Caso seu projeto use um provedor de serviços com um domínio comum compartilhado, recomendamos que você ative as configurações que permitam o uso do próprio domínio. Alguns provedores oferecem a opção de mapear os serviços para um subdomínio de um domínio que você já tenha.

Hospedar uma página inicial para apps de produção

Todo app de produção que usa o OAuth 2.0 precisa ter uma página inicial acessível publicamente. Os possíveis usuários do app podem visitar a página inicial para saber mais sobre os recursos e as funcionalidades oferecidas pelo app. Os usuários atuais podem analisar a lista de concessões atuais e acessar a página inicial do app como um lembrete do uso contínuo da oferta.

A página inicial do seu aplicativo precisa incluir uma descrição da funcionalidade do app, além de links para uma Política de Privacidade e Termos de Serviço opcionais. A página inicial precisa existir em um domínio verificado sob sua propriedade.

Usar URIs de redirecionamento seguros e origens JavaScript

Os clientes OAuth 2.0 para apps da Web precisam proteger os dados usando URIs de redirecionamento HTTPS e origens JavaScript, não o HTTP simples. O Google pode recusar as solicitações de OAuth que não forem originadas ou resolvidas para um contexto seguro.

Considere quais aplicativos e scripts de terceiros podem ter acesso a tokens e outras credenciais de usuário que retornam à sua página. Limite o acesso a dados confidenciais com locais de URI de redirecionamento limitados à verificação e armazenamento de dados do token.

Próximas etapas

Depois de garantir que seu app esteja em conformidade com as políticas do OAuth 2.0 nesta página, consulte Enviar para verificação da marca para ver detalhes sobre o processo de verificação.