Obedecer à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 seguir outras etapas para obedecer às políticas do OAuth 2.0 do Google. Neste guia, descrevemos como obedecer aos problemas mais comuns de desenvolvedores encontrados ao preparar seu app para produção. Isso ajuda você a alcançar o maior público possível com erros limitados.

Usar projetos separados para testes e produção

As políticas do 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 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 específicos de API, que podem incluir avaliações de segurança de terceiros.

  2. Analise 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 seu projeto de produção.
  3. Ative todas as APIs em uso pelos seus clientes.
  4. Revise a configuração da tela de consentimento do OAuth para o novo projeto no .
    5. .

Os clientes OAuth do Google usados na 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
  • Testar ou usar versões de pré-lançamento do app

Manter uma lista de contatos relevantes para o projeto

O Google e as APIs individuais que você ativar talvez precisem entrar em contato com você para informar sobre mudanças nos serviços ou novas configurações necessárias para seu projeto e os clientes dele. Revise as listagens do IAM do seu 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 projetos têm permissões para ações que modificam o estado, como a capacidade de fazer mudanças na tela de consentimento do 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 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 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. Enviamos e-mails para essas contas quando há notificações sobre seu projeto ou atualizações dos nossos serviços. Os administradores de organizações do Google Cloud precisam garantir que um contato acessível seja associado a todos os projetos da organização. Se não tivermos informações de contato atualizadas para 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 de marca precisam representar com precisão a identidade do seu app. As informações de marca do app são configuradas no OAuth .

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 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 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 distorcem a identidade ou tentam enganar os usuários.

Solicitar apenas os escopos necessários

Durante o desenvolvimento do 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 da API. Esses escopos de exemplo geralmente solicitam mais informações do que a implementação final do app precisa, porque eles oferecem cobertura abrangente de todas as ações possíveis para uma API específica. Por exemplo, o escopo de exemplo pode solicitar permissões de leitura, gravação e exclusão, enquanto seu app exige apenas permissões de leitura. Solicite permissões relevantes que sejam limitadas às informações essenciais necessárias para implementar seu aplicativo.

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

Para mais informações sobre esse requisito, leia a seção Solicitar apenas os escopos 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 de API do Google.

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

Alguns escopos são classificados como "restritos" ou "sensíveis" 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 app de produção usar escopos sensíveis ou restritos, será 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 são seus

O processo de verificação da tela de consentimento do 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 do JavaScript autorizadas. Revise a lista de domínios em uso pelo seu app, resumida na seção Domínios autorizados do editor de tela de consentimento do OAuth, e identifique os domínios que não são seus e, 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 projeto como proprietário ou editor.

Se o projeto usar um provedor de serviços com um domínio comum e compartilhado, recomendamos que você ative as configurações que permitiriam 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á tem.

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

Todos os apps de produção que usam o OAuth 2.0 precisam ter uma página inicial acessível ao público. Os usuários em potencial do app podem acessar a página inicial para saber mais sobre os recursos e as funcionalidades que ele oferece. Os usuários atuais podem analisar a lista de permissões atuais e visitar a página inicial do app como um lembrete de que eles continuam usando sua oferta.

A página inicial do app precisa incluir uma descrição da funcionalidade dele, 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 que você possui.

Usar URIs de redirecionamento seguros e origens do JavaScript

Os clientes OAuth 2.0 para apps da Web precisam proteger os dados usando URIs de redirecionamento HTTPS e origens do JavaScript, e não HTTP simples. O Google pode rejeitar solicitações OAuth que não são originadas ou resolvidas em 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 sensíveis com locais de redirecionamento de URI limitados à verificação e armazenamento de dados de 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 de marca para saber mais sobre o processo de verificação.