Obedecer às políticas do OAuth 2.0

Este guia descreve como entrar em conformidade com os problemas mais comuns encontrados pelos desenvolvedores ao preparar um app para produção.

Visão geral

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 seguir outras etapas para obedecer às políticas do OAuth 2.0 do Google. Neste guia, descrevemos como entrar em conformidade com os problemas mais comuns que os desenvolvedores encontram ao preparar o app para produção. Isso ajuda você a alcançar o maior público-alvo possível com o mínimo de erros.

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 se aplicam apenas a apps de produção. Talvez seja 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 em produção ajudam a fornecer um ambiente de coleta de dados 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, estar sujeito a requisitos adicionais para escopos de API específicos, que podem incluir avaliações de segurança de terceiros.

  1. Vá para o Console de APIs do Google. Clique em Criar projeto, insira um nome e clique em Criar.
  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 no projeto de produção.
  3. Ative todas as APIs em uso pelos clientes.
  4. Revise a configuração da tela de permissão OAuth do novo projeto na página Branding do console do Cloud.

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 sua equipe de desenvolvimento. Confira alguns exemplos:

  • Os servidores de teste de desenvolvedores individuais
  • Versões de teste ou de pré-lançamento do 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 para o projeto e os clientes. Revise as listagens do IAM do projeto para garantir que as 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 projeto.

Um papel contém um conjunto de permissões que permite realizar ações específicas nos recursos do projeto. Os editores de projeto têm permissões para ações que modificam o estado, como a capacidade de fazer mudanças na tela de permissão OAuth do projeto. Os proprietários do projeto que têm todas as permissões de editor podem adicionar ou remover contas associadas ao projeto ou excluí-lo. Os proprietários do projeto também podem fornecer contexto sobre o motivo de as informações de faturamento serem definidas. Os proprietários do projeto podem configurar informações de faturamento para um projeto que usa APIs pagas.

Os proprietários do projeto e editores precisam ser mantidos atualizados. É possível adicionar várias contas relevantes ao projeto para garantir o acesso contínuo a ele e à manutenção relacionada. Enviamos e-mails para essas contas quando há 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 exigem sua ação.

Represente sua identidade de maneira precisa

Informe um nome de app válido e, se quiser, um logotipo para mostrar aos usuários. Essas informações de marca precisam representar com precisão a identidade do seu aplicativo. As informações de branding do app são configuradas na página de branding do OAuth.

Para apps de produção, as informações de marca definidas na tela de permissão OAuth precisam ser verificadas antes de serem mostradas 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, que incluem o nome, a página inicial, os Termos de Serviço e a Política de Privacidade, são mostradas aos usuários na tela de concessão, quando eles revisam as concessões atuais, ou aos administradores do Google Workspace que revisam 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 deturpem a identidade ou tentem enganar os usuários.

Solicite apenas os escopos necessários

Durante o desenvolvimento do aplicativo, talvez você tenha usado um exemplo de escopo fornecido pela API para criar uma prova de conceito no aplicativo e saber mais sobre os recursos e as funcionalidades da API. Esses exemplos de escopos geralmente solicitam mais informações do que a implementação final do app precisa, porque eles fornecem uma cobertura abrangente de todas as ações possíveis para uma determinada API. Por exemplo, o escopo de exemplo pode solicitar permissões de leitura, gravação e exclusão, enquanto seu aplicativo requer apenas permissões de leitura. Solicite permissões relevantes que sejam limitadas às informações críticas necessárias para implementar o aplicativo.

Consulte a documentação de referência dos endpoints de API que seu app chama e anote os escopos necessários para acessar os dados relevantes de que seu app precisa. Revise os guias de autorização que a API oferece e descreva os escopos em mais detalhes para incluir o uso mais comum. Escolha o acesso mínimo aos dados necessário para que o aplicativo use os recursos relacionados.

Para mais informações sobre esse requisito, leia a seção Solicite apenas os escopos necessários das Políticas do OAuth 2.0, além da seção Solicite as permissões relevantes da Política de Dados do Usuário dos Serviços de API do Google.

Enviar apps de produção que usam escopos não sensíveis ou não restritos para verificação

O recurso Fazer Login com o Google não solicita escopos sensíveis e restritos ao autenticar um usuário. Se o aplicativo usa o recurso Fazer login com o Google apenas para autenticação, é necessário enviar o aplicativo para verificação de marca. É possível enviar para verificação no console do Google Cloud na página de branding. Essa verificação é necessária para mostrar elementos de marca do app, incluindo nome, logotipo, Política de Privacidade, Termos de Serviço e escopos, na tela de permissão.

Recomendamos que seu app siga as diretrizes de branding oficiais para posicionar o botão de login.

Use apenas domínios que você possui

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 projeto, à Política de Privacidade, aos Termos de Serviço, aos URIs de redirecionamento autorizados ou às origens de JavaScript autorizadas. Revise a lista de domínios em uso pelo app, resumida na seção Domínios autorizados do editor da tela de permissão OAuth, e identifique os domínios que não pertencem a você e que, portanto, não podem ser verificados. 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 do Console de APIs como proprietário ou editor.

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

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 ao público. Os usuários em potencial do seu app podem acessar a página inicial para saber mais sobre os recursos e as funcionalidades que ele oferece. Os usuários atuais podem revisar a lista de concessões atuais e acessar a página inicial do app como um lembrete do uso contínuo da sua oferta.

A página inicial do 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 estar em um domínio verificado de sua propriedade.

Usar URIs de redirecionamento e origens de JavaScript seguros

Os 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 originam ou não são resolvidas em 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 sensíveis com locais de URI de redirecionamento que se limitam a verificar e armazenar dados de token.

Próximas etapas

Depois de garantir que seu app obedece às políticas do OAuth 2.0 nesta página, consulte Enviar para verificação de marca para saber mais sobre o processo de verificação.