Подключение настольного приложения к Google Фото без раскрытия секретного ключа приложения

Я пишу на Java автономное настольное приложение с открытым исходным кодом, которое обрабатывает фотографии, и добавляю функцию, позволяющую пользователям загружать изображения в свою учетную запись Google Фото, но столкнулся с вопросом аутентификации/безопасности.

Я зарегистрировал свой проект для использования Google Photo API и загрузил файл JSON с моими учетными данными. Мне удалось успешно использовать его с примерами из проекта java-photoslibrary Github, так что все хорошо.

Однако в файле учетных данных содержится ключ client_secret, который, если я не ошибаюсь, не следует разглашать (здесь я прав?). Но эти учетные данные должны каким-то образом распространяться вместе с приложением, и, поскольку оно имеет открытый исходный код, оно будет в основном общедоступным. Итак, мой вопрос: как я могу аутентифицировать пользователя моего приложения в его / ее учетной записи Google Photo, не раскрывая секретный ключ моего приложения?

Примечание. Я интегрировал загрузку в Dropbox, и их процедура для настольных приложений четко объясняет, как пройти аутентификацию без внедрения секретного ключа в настольное приложение с использованием потока токенов OAuth. Есть ли аналог для Google Фото?

Спасибо.

Редактировать: достигнут некоторый прогресс (см. мой собственный ответ ниже), но после того, как у меня наконец появилось время для его реализации, я понял, что после того, как пользователь авторизовал приложение и был возвращен действительный код (ура!), шаг 5 (обмен кодом для токена) снова требуется client_secret ! :-(

Я пробовал звонить без него, но получаю сообщение об ошибке client_secret ismissing, так что это не опечатка.

После дополнительного поиска (с ключевым словом [google-oauth] вместо [oauth-2.0], что говорит само за себя), кажется, что секрет не означает, что он на самом деле секретен в мире Google. Другими словами, это нормально встраивать его в ваши приложения, потому что, ну, это секрет, но его нельзя использовать злонамеренным образом (надеюсь)...

См. ответы на эти связанные вопросы:

На на одной странице Google даже упоминается, что в этом контексте секрет клиента явно не рассматривается как секрет.

Давай, Гугл, объясни мне, как работает безопасность :-)


person Vicne    schedule 16.06.2020    source источник
comment
Это отдельное клиентское приложение или клиент-сервер?   -  person Ralph    schedule 17.06.2020
comment
Автономный (только что обновил вопрос). Спасибо.   -  person Vicne    schedule 17.06.2020
comment
Можете ли вы поделиться ссылкой на документацию Dropbox, упомянутую выше?   -  person Ralph    schedule 17.06.2020
comment
Конечно. Мой случай был похож на этот вопрос — dropboxforum.com/t5/Dropbox-API-Support-Feedback/ . Начиная с этого, я реализовал PKCE, который в основном создает случайное число, шифрует его с помощью открытого ключа приложения и отправляет его в Dropbox. Dropbox запрашивает у пользователя подтверждение и отвечает кодом, который можно сопоставить и преобразуется приложением в токен пользователя для использования в последующих запросах. секретный ключ приложения ни в коем случае не задействован.   -  person Vicne    schedule 17.06.2020


Ответы (1)


Хорошо, я думаю, что нашел ответ.

Подобно Dropbox, Google может использовать OAuth 2 с PKCE, они просто используют ключ проверки правописания для обмена кодами, вероятно, поэтому я сначала не нашел его :-). Подробности здесь: https://developers.google.com/identity/protocols/oauth2/native-app#obtainingaccesstokens

Я не нашел эквивалентного процесса в API Google, но эти API представляют собой мегабайты классов, поэтому я мог его пропустить. По сути, все, что требуется, — это просто отправить несколько запросов и прослушать ответ, поэтому я думаю, что реализую его с нуля (и, вероятно, также избавлюсь от клиентских библиотек Dropbox, поскольку процесс очень похож).

Надеюсь, поможет...

Изменить: это не решает проблему, потому что после чистой процедуры PKCE приложение все равно должно отправить свой закрытый ключ для обмена кода авторизации на токен. Смотрите редактирование в моем вопросе

person Vicne    schedule 19.06.2020