Google OAuth2 в распространенных самодостаточных пакетах, жалующихся на redirect_uri

Question

Я принял участие в разработке панели инструментов API Google Analytics для платформы управления контентом и обновил код для использования OAuth2, поскольку в последнее время был отключен более старый oauth. Поток аутентификации и последующие вызовы API полностью работают на моем localhost для разработки.

Проблема при попытке кода из другого домена. Google хочет redirect_uri будет Whitelisted через консоль разработчика, а если нет, он бросает Error: redirect_uri_mismatch

Как это резидентный (+ с открытым исходным кодом) пакета, люди будут иметь возможность установки на их собственные серверы, я никак не могу добавить все возможные значения redirect_uri в ключ приложения в консоли разработчика.

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

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

2. Используйте значение redirect_uri urn:ietf:wg:oauth:2.0:oob с ключом Установленного приложения, инструктируя людей копировать/вставлять код обратно в самообслуживаемое приложение после аутентификации.

Ни один из них не является действительно привлекательным, поскольку он добавляет кучу сложности для пользователя (хотя вариант 2 звучит в основном выполнимо). Есть ли другие варианты, или я просто пропускаю что-то простое?

Answer 1

У вас на самом деле нет выбора в этом вопросе. Вы должны пойти с nr 1. Когда вы укажете, что это панель инструментов и веб-приложение, это заставляет меня поверить, что это какой-то язык сценариев. Это означает, что клиентский идентификатор и клиентский секрет будут отображаться вашим пользователям/клиентам. Это противоречит условиям обслуживания googles.

Changes to the Google APIs Terms of Service
Запрашиваемые разработчикам разумные усилия, чтобы сохранить свои ключи приватным и не встраивать их в проектах с открытым исходным кодом.

Вы не можете освобождать свой идентификатор клиента и секрет клиента для своих пользователей, которые им придется создавать самостоятельно. Что красиво решает вашу проблему URI перенаправления, которую они должны сделать.

Дополнительная информация Can I really not ship open source with Client ID?