Conformidade com as 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 medidas adicionais para obedecer às políticas do OAuth 2.0 do Google. Neste guia, descrevemos como entrar em conformidade com os problemas mais comuns de desenvolvedores encontrados ao preparar seu app para produção. Isso ajuda a alcançar o maior público-alvo possível com erros limitados.

Usar projetos separados para teste e produção

As políticas de OAuth do Google exigem projetos separados para teste e produção. Algumas políticas e requisitos só se aplicam a apps de produção. Pode ser necessário criar e configurar um projeto separado que inclua clientes OAuth correspondentes à versão de produção do app disponível para todas as Contas do Google.

Os clientes OAuth do Google usados na produção ajudam a fornecer um ambiente de coleta e armazenamento de dados mais estável, previsível e seguro que os 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 outros requisitos para escopos específicos da API, 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 qualquer API em uso pelos seus clientes.
  4. Revise a configuração da tela de consentimento OAuth no novo projeto.

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

  • Os servidores de teste de desenvolvedores individuais
  • Versões de teste ou pré-lançamento do seu app

Manter uma lista de contatos relevantes para o projeto

O Google e as APIs individuais que você ativar podem precisar entrar em contato com você sobre mudanças nos serviços ou novas configurações necessárias do seu projeto e dos clientes dele. Revise as listagens do IAM do seu projeto para garantir que pessoas relevantes da sua equipe tenham acesso para editar ou visualizar a configuração do projeto. Essas contas também podem receber e-mails sobre mudanças necessárias no seu 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 permissão 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 explicar 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.

Proprietários e editores de projetos devem estar atualizados. É possível adicionar várias contas relevantes ao projeto para ajudar a garantir o acesso contínuo a ele e à manutenção relacionada. Enviamos e-mails para essas contas quando recebemos 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 na organização. Se não tivermos dados de contato atualizados para seu projeto, talvez você perca mensagens importantes que exijam sua ação.

Represente com precisão sua identidade

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

Para apps de produção, as informações da marca definidas na sua tela de permissão OAuth precisam ser verificadas antes que sejam exibidas aos usuários. É mais provável que os usuários concedam acesso ao seu app depois que ele concluir a verificação de marca. As informações básicas do aplicativo, como nome, página inicial, Termos de Serviço e Política de Privacidade, são mostradas aos usuários na tela de concessão, quando eles analisam as concessões atuais ou aos administradores do Google Workspace que analisam o uso do app 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.

Somente os escopos de solicitação necessários

Durante o desenvolvimento do aplicativo, talvez você tenha 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 dela. Esses escopos de exemplo geralmente solicitam mais informações do que a implementação final do app precisa, porque oferecem 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 essenciais necessárias para implementar seu aplicativo.

Consulte a documentação de referência dos endpoints de API que seu app chama e observe os escopos necessários para acessar os dados relevantes de que o app precisa. Revise os guias de autorização que a API oferece e descreva os escopos deles com mais detalhes para incluir o uso mais comum. Escolha o acesso mínimo aos dados que seu 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 e a seção Solicitar permissões relevantes da política de dados do usuário dos serviços de APIs do Google.

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

Alguns escopos são classificados como "sensíveis" ou "restritos" e não podem ser usados em apps de produção sem revisão. Insira todos os escopos que o app de produção usa na Configuração da tela de consentimento do OAuth. Se o aplicativo de produção usa escopos confidenciais ou restritos, é necessário enviar o uso desses escopos para verificação antes de incluí-los em uma solicitação de autorização.

Usar apenas domínios que pertencem a você

O processo de verificação da tela de permissão OAuth do Google requer a verificação de todos os domínios associados à página inicial do projeto, à Política de Privacidade, aos Termos de Serviço, aos URIs de redirecionamento autorizados ou às origens do JavaScript autorizadas. Revise a lista de domínios em uso pelo app, resumida na seção Domínios autorizados do editor de tela de consentimento do OAuth, e identifique todos os domínios que não pertencem a você e, portanto, 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.

Se o projeto usa um provedor de serviços com um domínio comum e compartilhado, recomendamos ativar as configurações que permitem o uso do próprio domínio. Alguns provedores se oferecem para mapear os serviços para um subdomínio de um domínio que você já tem.

Hospedar uma página inicial para aplicativos 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 podem acessar a página inicial para saber mais sobre os recursos e as funcionalidades que ele oferece. Os usuários podem analisar a lista de benefícios e acessar a página inicial do app para lembrar que estão usando sua oferta de forma contínua.

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

Usar URIs de redirecionamento seguro e origens do JavaScript

Clientes OAuth 2.0 para apps da Web precisam proteger os dados usando URIs de redirecionamento HTTPS e origens JavaScript, não HTTP simples. O Google pode rejeitar solicitações OAuth que não se originem ou resolvam para um contexto seguro.

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

Próximas etapas

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