Могу ли я действительно не отправлять с открытым исходным кодом идентификатор клиента?

Учетные данные разработчика (например, пароли, ключи и идентификаторы клиентов) предназначены для использования вами и идентифицируют клиента API. Вы будете хранить свои учетные данные в конфиденциальном порядке и предпринимать разумные меры для предотвращения и отказа от других клиентов API от использования ваших учетных данных. Учетные данные разработчика не могут быть встроены в проекты с открытым исходным кодом.

(https://developers.google.com/terms/, мой акцент)

Означает ли это, что моему клиенту командной строки с открытым исходным кодом необходимо заставить каждого пользователя моего программного обеспечения создать новый проект на консоли Google Cloud? Есть ли лучший вариант?

Не так сложно извлечь идентификатор клиента и "секрет" клиента из не-openource, так почему же различие?

"Установить приложения" идентификаторы клиентов и секреты на самом деле не являются секретами, и документация Google, похоже, согласна:

В результате процесса создается идентификатор клиента и, в некоторых случаях, секрет клиента, который вы вставляете в исходный код приложения. (В этом контексте секрет клиента явно не рассматривается как секрет.)

(https://developers.google.com/accounts/docs/OAuth2, снова мой акцент)

Ответы

Ответ 1

5 ноября 2014 года Google внесла некоторые изменения в условия обслуживания API.

Как и у вас возникла проблема со следующей строкой.

Просить разработчиков приложить все усилия, чтобы сохранить свои личные ключи закрыты и не внедряют их в проекты с открытым исходным кодом.

У меня есть несколько проектов с открытым исходным кодом на GitHub, они в основном являются учебниками по использованию API Google. Некоторые из API все еще находятся в стадии бета-тестирования, и для получения бета-доступа требуется время. У меня был мой идентификатор клиента, встроенный в мои проекты, чтобы мои пользователи могли тестировать приложения.

Теперь у меня есть некоторые контакты в Google, поэтому я надеялся, что смогу получить здесь какое-то разрешение. Мне удалось отследить автора вышеупомянутой оскорбительной смены службы Дэн Цирули и отправил ему электронное письмо.

Мое электронное письмо было достаточно логичным, вы можете прочитать его здесь: Изменения службы

Короче говоря, нет, вы не можете освободить свой идентификатор клиента с помощью проекта с открытым исходным кодом, здесь Дэн по электронной почте мне объясняет, почему.

Вы, однако, позволяете им "выдавать себя за вас" в глазах Гуггла. Если наши системы злоупотребления обнаруживают злоупотребления (скажем, если кто-то попытается сделать DoS один наших услуг, используя ваш ключ), вы рискуете, что прекратите свою учетную запись из-за этого (и, пожалуйста, обратите внимание - они не будут просто разрезали доступ к ключу, они закрывали бы вашу консоль Счет). Кроме того, вам был предоставлен доступ в белый список к API которые недоступны для широкой публики (и, по всей вероятности, требуется согласие с отдельными Условиями обслуживания) и доступ к любому, кто этого хочет. Несомненно, что это нарушение этих терминов. Извините, что у вас нет ответа, которого вы ищете, но ключи - это один из способов, которым мы должны сказать, кто звонит в наши сервисы.

Это всего лишь часть его электронной почты. Вы можете прочитать полный пост по ссылке выше. Поэтому, если вы даете им исходный код, и они могут видеть идентификатор клиента. Вашим пользователям придется создавать собственный проект на консоли Google Cloud. Об этом нет.

Надеюсь, это помогло.

Ответ 2

Существует лучший вариант, и он называется OAuth 2.0 Dynamic Client Registration. Это все еще продолжается, но: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21, и для провайдеров может потребоваться некоторое время.

Изменить:

Категорически невозможно отправить секреты аутентификации с помощью приложения с открытым исходным кодом. [Честно говоря, на самом деле не имеет смысла отправлять их с помощью любого приложения; это сразу становится очевидным с помощью приложений с открытым исходным кодом.]