Eu realmente não posso enviar código aberto com o ID do cliente?

As credenciais de desenvolvedor (como senhas, chaves e IDs de cliente) devem ser usadas por você e identificar seu cliente de API. Você manterá suas credenciais confidenciais e fará esforços razoáveis ​​para impedir e desencorajar outros clientes da API a usar suas credenciais. As credenciais de desenvolvedor não podem ser incorporadas em projetos de código aberto.

( https://developers.google.com/terms/ , minha ênfase)

Isso significa que meu cliente de linha de comando do Open Source Drive precisa forçar todos os usuários do meu software a configurar um novo projeto no console do Google Cloud? Existe uma opção melhor?

Não é difícil extrair ID de cliente e “segredo” de cliente de não-opensource, então por que a distinção?

Os IDs de clientes e os segredos “Instalar aplicativos” não são realmente segredos, e a documentação do Google parece concordar:

O processo resulta em um ID de cliente e, em alguns casos, em um segredo de cliente, que você incorpora no código-fonte de seu aplicativo. ( Neste contexto, o segredo do cliente obviamente não é tratado como um segredo. )

( https://developers.google.com/accounts/docs/OAuth2 , novamente minha ênfase)

    Em 5 de novembro de 2014, o Google fez algumas alterações nos termos de serviço das APIs .

    Como você eu tive um problema com a seguinte linha.

    Pedir aos desenvolvedores que façam esforços razoáveis ​​para manter suas chaves privadas privadas e não incorporá-las em projetos de código aberto.

    Eu tenho vários projetos de código aberto no GitHub eles são basicamente tutoriais para usar as APIs do Google, algumas das APIs ainda estão em beta e leva tempo para obter access beta. Eu tinha meu ID de cliente embutido em meus projetos para que meus usuários pudessem testar os aplicativos.

    Agora eu tenho alguns contatos no Google, então eu estava esperando que eu conseguisse algum tipo de dispensação aqui. Consegui localizar o autor da mudança de serviço acima mencionada, Dan Ciruli, e enviei-lhe um email.

    Meu e-mail foi bastante log você pode lê-lo aqui: Mudanças de serviço

    Para fazer uma longa história curta Não, você não pode liberar o seu ID de cliente com o seu projeto de código aberto, aqui está o e-mail de Dan para mim explicando o porquê.

    Você está, no entanto, permitindo que eles “personifiquem” você aos olhos do Google. Se nossos sistemas de abuso detectarem abuso (digamos, se alguém tentar fazer DoS um de nossos serviços usando sua chave), você corre o risco de encerrar sua conta por causa disso (e, por favor, observe – eles não apenas cortariam o access à chave, eles desligariam sua conta de console). Além disso, você recebeu access permitido a APIs que não estão disponíveis para o público em geral (e, com toda a probabilidade, exigem o consentimento de um Termo de Serviço separado) e estão compartilhando o access a qualquer pessoa que deseje. Não há dúvida de que é uma violação desses termos. Desculpe por não ter a resposta que você está procurando, mas as chaves são a única maneira que temos para dizer quem está chamando nossos serviços.

    Isso é apenas parte do seu email de volta para mim. Você pode ler o post completo no link acima. Então, se você está dando a eles o código fonte e eles podem ver o ID do cliente. Seus usuários precisarão criar um projeto próprio no console do Google Cloud. Não há maneira de contornar isso.

    Espero que isso tenha ajudado.

    Existe uma opção melhor e é chamada de Registro de Cliente Dinâmico OAuth 2.0. Esse ainda é um trabalho em andamento: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21 e pode demorar um pouco para que os Provedores o adotem e implementem.

    Editar:

    É categoricamente impossível enviar segredos de autenticação com um aplicativo de código aberto. [Honestamente, não faz sentido enviá-los com qualquer aplicativo; é apenas mais imediatamente óbvio com aplicativos de código aberto.]