Neste guia, vamos orientá-lo sobre como corrigir você não pode fazer login neste aplicativo porque ele não está em conformidade com a política OAuth 2.0 do Google. Portanto, se você está navegando na internet há horas para superar a situação, pode confiar neste blog. Então, sem mais delongas, vamos começar. Mas antes disso vamos discutir sobre a política OAuth 2.0 do Google.
O que é OAuth?
O protocolo OAuth (Open Authorization) foi desenvolvido pela Internet Engineering Task Force e permite acesso delegado seguro. Isso permite que um aplicativo acesse um recurso controlado por outra pessoa (usuário final). Esse tipo de acesso precisa de Tokens, que representam direito de acesso delegado. É por isso que os aplicativos obtêm acesso sem se passar pelo usuário que controla o recurso.
Aqui neste blog, tentamos fornecer algumas etapas para cumprir as políticas de OAuth 2.0 do Google. Para que você possa seguir as diretrizes para estar em conformidade com os problemas de desenvolvedor mais comuns encontrados ao preparar seu aplicativo para produção. Isso ajudará você a alcançar o maior público possível com erros limitados.
Use projetos separados para teste e produção
As políticas do Google OAuth precisam de projetos separados para teste e produção. Algumas das políticas e requisitos são aplicados apenas a aplicativos de produção. Portanto, 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 são usados na produção e ajudam a fornecer um ambiente de coleta e armazenamento de dados previsível, mais estável e seguro do que os mesmos clientes OAuth 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 provavelmente incluem avaliações de segurança de terceiros.
Etapa 1: navegue até o Google API Console , toque em Criar projeto, insira o nome e toque em Criar
Etapa 2: revise os clientes OAuth no projeto que pode estar vinculado à sua camada de teste. Se aplicável, crie clientes OAuth semelhantes para os clientes de produção no projeto de produção.
Etapa 3: em seguida, habilite quaisquer APIs em uso por seus clientes
Etapa 4: depois disso, revise a configuração da tela de consentimento do OAuth no novo projeto.
Os clientes Google OAuth usados em produção não devem ter ambientes de teste, URIs de redirecionamento ou origens de Java Script disponíveis apenas para você ou sua equipe de desenvolvimento. Listamos alguns exemplos:
- Os servidores de teste dos desenvolvedores individuais
- Teste ou versões de pré-lançamento do aplicativo
Manter uma lista de contatos relevantes para o Projeto
O Google e as APIs individuais que você ativou podem precisar entrar em contato com você sobre as alterações em seus serviços ou novas configurações exigidas do projeto e de seus clientes. Agora revise as listagens do IAM do projeto para garantir que pessoas importantes da sua equipe tenham acesso para editar ou visualizar a configuração do seu projeto. Observe que essas contas também podem receber e-mails sobre as alterações necessárias no projeto.
A função consiste em um conjunto de permissões que permite ao usuário executar ações específicas nos recursos do projeto. Os editores de projeto têm permissão para as ações que modificam o estado, como a capacidade de fazer alterações na tela de consentimento OAuth do projeto. Os proprietários do projeto que têm todas as permissões de editor podem adicionar ou excluir contas vinculadas ao projeto ou excluir o projeto. Os Proprietários do Projeto também podem oferecer contexto sobre o motivo pelo qual as informações de cobrança podem ser 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 os editores devem ser mantidos atualizados. Você pode adicionar várias contas relacionadas ao projeto para ajudar. Certifique-se de acesso contínuo ao projeto e à manutenção relacionada. Os e-mails são recebidos pelas contas que possuem notificações sobre o projeto ou atualizações em nossos serviços. Os administradores da organização do Google Cloud precisam garantir que um contato acessível esteja vinculado a todos os projetos da organização. E se não houver informações de contato atualizadas para o seu projeto, é provável que você perca mensagens obrigatórias que exigem sua ação.
Aviso: a não ação em notificações oportunas sobre o projeto pode resultar na perda de acesso às APIs do Google.
Pontos a serem lembrados: um dos contatos relevantes para o projeto é o email de suporte ao usuário configurado para a tela de consentimento do OAuth. E se os usuários tiverem problemas com seu aplicativo ou os administradores do Google Cloud Organization tiverem dúvidas em nome de seus usuários, este endereço de e-mail será exibido para que eles possam entrar em contato.
Representar com precisão sua identidade
Você precisa fornecer um nome de aplicativo genuíno, opcionalmente, um logotipo para mostrar aos usuários. Essas informações de marca podem representar exatamente a identidade do aplicativo. As informações de marca do aplicativo são configuradas na página da tela de consentimento do OAuth.
E para os aplicativos de produção, as informações da marca definidas na tela de consentimento do OAuth devem ser confirmadas antes de serem exibidas aos usuários. Os usuários podem estar mais propensos a conceder acesso ao aplicativo depois de concluir a verificação da marca. As informações básicas do aplicativo, que incluem o nome do aplicativo, a página inicial, os termos de serviço e a política de privacidade, são exibidas aos usuários na tela de concessão e quando eles revisam as concessões existentes ou aos administradores do Google Workspace que revisam o uso do aplicativo pela organização
O Google pode revogar ou suspender o acesso ao Google API Service e a outros produtos e serviços do Google para aplicativos que falsificam sua identidade ou tentam enganar os usuários.
Solicite apenas escopos que você deseja
Durante o desenvolvimento do seu aplicativo, você pode ter usado um escopo de exemplo oferecido pela API para fazer uma prova de conceito dentro do seu aplicativo para aprender mais sobre os recursos e funcionalidades das APIs. Esses escopos de exemplo frequentemente solicitam mais informações do que a implementação final do aplicativo precisa, pois oferecem uma ampla cobertura 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 seu aplicativo precisa apenas de permissões de leitura, Solicitar permissões relevantes que são limitadas a informações críticas essenciais para implementar o aplicativo.
Agora revise a documentação de referência para o endpoint de API que seu aplicativo chama e observe os escopos que eles precisam para acessar os dados relacionados que nosso aplicativo requer. Em seguida, revise quaisquer guias de autorização que a API oferece e descreva os escopos com mais detalhes para incluir o uso mais comum. Selecione o acesso mínimo de dados que seu aplicativo requer para alimentar os recursos associados.
Enviar aplicativos de produção que usam escopos confidenciais ou limitados para verificação
Bem, certos escopos são classificados como “Sensíveis” ou “Restritos” e não podem ser usados em aplicativos de produção sem revisão. Você precisa inserir todos os escopos que seu aplicativo de produção usa em sua configuração de tela de consentimento OAuth. Observe que, se seu aplicativo de produção usa escopos confidenciais ou limitados, você deve enviar seu uso de escopos para a verificação antes de incluir escopos em uma solicitação de autorização.
Use apenas domínios que você possui
O processo de verificação da tela de consentimento OAuth do Google precisa da verificação de todos os domínios relacionados à página inicial do projeto, política de privacidade, termos de serviço, URIs de redirecionamento autorizados ou origens de Java Script autorizados. Em seguida, revise a lista de domínios em uso pelo seu aplicativo e resumida na seção Domínios autorizados do editor de tela de consentimento do OAuth e reconheça qualquer domínio que você não possui e, portanto, não poderia verificar. Para verificar a propriedade dos domínios autorizados do projeto, use o Google Search Console. Depois disso, use a Conta do Google relacionada ao projeto do console de API como proprietário ou editor.
E se o seu projeto usa um provedor de serviços com um domínio comum compartilhado, recomendamos habilitar configurações que possam permitir o uso de seu próprio domínio. Alguns provedores oferecem o mapeamento de seus serviços para o subdomínio de um domínio que você já possui.
Use URIs de redirecionamento seguro e origens de JavaScript
Os clientes OAuth 2.0 para páginas da Web devem proteger seus dados que usam URIs de redirecionamento HTTPS e origens JavaScript, não HTTP simples. O Google pode rejeitar solicitações OAuth que não iniciam ou resolvem para um conteúdo seguro.
Agora considere quais aplicativos e scripts de terceiros podem ter acesso aos tokens e às outras credenciais de usuário que retornam a essa página. Agora, limitar o acesso aos dados confidenciais redirecionará os locais de URI que são restritos à verificação e armazenamento de dados de token.
Próximos passos
Depois de garantir que seu aplicativo seja compilado com as políticas do OAuth 2.0 na página, consulte Enviar para verificação de marca para obter detalhes sobre o processo de verificação.
Conclusão
Isso é tudo sobre você não pode fazer login neste aplicativo porque ele não está em conformidade com a política OAuth 2.0 do Google. Espero que tenha gostado do blog. Obrigado pela leitura.