Как использовать API Google без постоянного явного согласия пользователя от прогрессивного веб-приложения?

Question

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

Поскольку загрузка должна выполняться нав фоновом режиме, когда пользователь снова подключен к сети (с использованием работника службы и одноразового API фоновой синхронизации), токена доступа недостаточно для моей потребности (пользователь может быть отключен от сети / не использовать веб-приложение в течение нескольких дней) и обновлениеНасколько я понимаю, токен не должен храниться на стороне клиента веб-приложения.Даже если бы это было так, мне все равно понадобился бы секрет клиента, а это значит, что я должен использовать сервер (или хранить секрет на стороне клиента веб-приложения, а это нет-нет), чтобы обновить токен.

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

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

Сохранение токена обновления на стороне клиента веб-приложения и просто обращение к серверу для фактического обновления токена доступа (ничего не должно храниться на стороне сервера, кроме секрета клиента, что хорошо), но, как я уже говорил, я понимаю,токен обновления не должен храниться на стороне веб-приложения.

Существует ли безопасный и надежный способ реализовать это без сервера (или с сервера, который получает только токен обновления и возвращает егоклиент и обновляет токен доступа, получая токен обновления от клиента)?

Answer 1

Это на самом деле довольно просто, в зависимости от мелких деталей вашего варианта использования.

Важным фактом является то, что, как только пользователь предоставил разрешение вашему приложению, ему не нужно будет повторно предоставлять его.Таким образом, вам не нужно «постоянно запрашивать авторизацию при загрузке в фоновом режиме».Однако единственным ограничением является то, что пользователь должен войти в систему Google, чтобы получить токен доступа.Обычно это не проблема, но ваше приложение должно иметь дело со сценарием, когда пользователь вышел из Google, и запросить логин.

Все подробности здесь https://developers.google.com/identity/protocols/OAuth2UserAgent

Я предлагаю избегать библиотеки Google JS, потому что (а) у нее есть свое собственное мнение о UX, (б) не было написано с учетом PWA, (в) есть проблемы на мобильном телефоне, и (г) закрытый источник, поэтому, когдаон ломается (как это иногда бывает), ваши пользователи мертвы в воде, пока Google не исправит это.На приведенной выше странице подробно описаны конечные точки OAuth, поэтому вы можете легко использовать их напрямую.Это дает дополнительное преимущество, заключающееся в том, что добавление других учетных записей облачного хранилища (AWS, Azure, Drop и т. Д.) - это всего лишь случай изменения URL-адреса конечной точки.

Архитектура, которую я использую в своей PWA, заключается в том, чтобы один раз получить приглашение PWA.(и только один раз) для авторизации, а затем сохраните адрес Gmail пользователя в localStorage.Затем у меня есть скрытый iframe, который опрашивает токен доступа один раз в час, используя адрес gmail в login_hint.Это означает, что iframe никогда не требуется для представления какого-либо UX.Единственный раз, когда требуется UX, это для первоначальной аутентификации, которая, конечно, неизбежна, и один раз за сеанс, если пользователь вышел из Google.

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

В более широком смысле, помните, что Google не создавал спецификацию OAuth, поэтому они мало что могут сделать, чтобы предоставитьальтернативное решение.На абстрактном уровне аутентификация требует присутствия одного из пользователей или безопасного хранилища для постоянного токена (например, на сервере или в безопасном хранилище, таком как Android).Даже если мы изобретем OAuth 3, это все равно будет так.