На этой странице описаны некоторые общие рекомендации по интеграции с OAuth 2.0. Рассмотрите эти рекомендации в дополнение к любым конкретным рекомендациям для вашего типа приложения и платформы разработки. Также ознакомьтесь с советами по подготовке вашего приложения к производству и политиками Google OAuth 2.0 .
Безопасно обрабатывайте учетные данные клиентов
Учетные данные клиента OAuth идентифицируют личность вашего приложения, и с ними следует обращаться осторожно. Храните эти учетные данные только в безопасном хранилище, например, с помощью диспетчера секретов, такого как Google Cloud Secret Manager . Не кодируйте учетные данные жестко, не сохраняйте их в репозитории кода и не публикуйте публично.
Безопасно обрабатывайте токены пользователей
Токены пользователя включают в себя как токены обновления, так и токены доступа, используемые вашим приложением. Храните токены в безопасном состоянии и никогда не передавайте их в виде обычного текста. Используйте безопасную систему хранения, подходящую для вашей платформы, например Keystore на Android, Keychain Services на iOS и macOS или Credential Locker на Windows.
Отзовите токены , как только они больше не нужны, и навсегда удалите их из своих систем.
Кроме того, рассмотрите следующие рекомендации для вашей платформы:
- Для серверных приложений, которые хранят токены для многих пользователей, зашифруйте их при хранении и убедитесь, что ваше хранилище данных не является общедоступным из Интернета.
- Для собственных настольных приложений настоятельно рекомендуется использовать протокол Proof Key for Code Exchange (PKCE) для получения кодов авторизации, которые можно обменять на токены доступа.
Обработка отзыва и истечения срока действия токена обновления.
Если ваше приложение запросило токен обновления для автономного доступа , вам также необходимо обработать его аннулирование или истечение срока действия. Токены могут быть признаны недействительными по разным причинам , например, срок их действия истек или доступ к вашим приложениям мог быть отозван пользователем или автоматическим процессом. В этом случае тщательно продумайте, как ваше приложение должно реагировать, включая запрос пользователю при следующем входе в систему или очистку его данных. Чтобы получать уведомления об отзыве токена, интегрируйтесь со службой защиты нескольких учетных записей .
Используйте дополнительную авторизацию
Используйте добавочную авторизацию для запроса соответствующих областей OAuth, когда эта функциональность необходима вашему приложению.
Не следует запрашивать доступ к данным при первой аутентификации пользователя, за исключением случаев, когда это необходимо для основных функций вашего приложения. Вместо этого запрашивайте только те области, которые необходимы для задачи, следуя принципу выбора минимально возможных и наиболее ограниченных областей .
Всегда запрашивайте области в контексте, чтобы помочь пользователям понять, почему ваше приложение запрашивает доступ и как данные будут использоваться.
Например, ваше приложение может следовать этой модели:
- Пользователь проходит аутентификацию в вашем приложении
- Никаких дополнительных объемов не требуется. Приложение предоставляет базовые функции, позволяющие пользователю исследовать и использовать функции, не требующие дополнительных данных или доступа.
- Пользователь выбирает функцию, требующую доступа к дополнительным данным.
- Ваше приложение отправляет запрос на авторизацию для этой конкретной области OAuth, необходимой для этой функции. Если для этой функции требуется несколько областей, следуйте приведенным ниже рекомендациям .
- Если пользователь отклоняет запрос, приложение отключает эту функцию и предоставляет пользователю дополнительный контекст для повторного запроса доступа.
Обработка согласия для нескольких областей
При одновременном запросе нескольких областей пользователи могут не предоставить все запрошенные вами области OAuth. Ваше приложение должно обрабатывать отказ в областях, отключив соответствующие функции.
Если базовая функциональность вашего приложения требует нескольких областей, объясните это пользователю, прежде чем запрашивать согласие.
Вы можете предложить пользователю еще раз только после того, как он четко обозначит намерение использовать конкретную функцию, требующую этой области. Ваше приложение должно предоставить пользователю соответствующий контекст и обоснование, прежде чем запрашивать области OAuth.
Вам следует минимизировать количество областей, запрашиваемых вашим приложением одновременно. Вместо этого используйте дополнительную авторизацию для запроса областей в контексте функций и возможностей.
Используйте безопасные браузеры
В Интернете запросы авторизации OAuth 2.0 должны выполняться только из полнофункциональных веб-браузеров. На других платформах обязательно выберите правильный тип клиента OAuth и интегрируйте OAuth в соответствии с вашей платформой. Не перенаправляйте запрос через встроенные среды просмотра, включая веб-просмотры на мобильных платформах, например WebView на Android или WKWebView на iOS. Вместо этого используйте собственные библиотеки OAuth или вход в Google для вашей платформы.
Ручное создание и настройка клиентов OAuth.
Во избежание злоупотреблений клиенты OAuth не могут создаваться или изменяться программным способом. Вам необходимо использовать консоль разработчиков Google, чтобы явно принять условия обслуживания, настроить клиент OAuth и подготовиться к проверке OAuth.
Для автоматизированных рабочих процессов рассмотрите возможность использования сервисных учетных записей .