Рекомендации

Безопасная обработка учетных данных клиентов

Учётные данные клиента OAuth идентифицируют ваше приложение и требуют осторожного обращения. Храните эти учётные данные только в безопасном хранилище, например, используя менеджер секретов, такой как Google Cloud Secret Manager . Не прописывайте учётные данные жёстко, не фиксируйте их в репозитории кода и не публикуйте публично.

Безопасное обращение с токенами пользователей

Пользовательские токены включают в себя как токены обновления, так и токены доступа, используемые вашим приложением. Храните токены в безопасности и никогда не передавайте их в виде обычного текста. Используйте безопасную систему хранения, подходящую для вашей платформы, например, Keystore на Android, Keychain Services на iOS и macOS или Credential Locker на Windows.

Отзовите токены , как только они больше не нужны, и навсегда удалите их из своих систем.

Кроме того, рассмотрите следующие рекомендации для вашей платформы:

• Для серверных приложений, хранящих токены для многих пользователей, шифруйте их в состоянии покоя и убедитесь, что ваше хранилище данных недоступно публично из Интернета.
• Для собственных настольных приложений настоятельно рекомендуется использовать протокол Proof Key for Code Exchange (PKCE) для получения кодов авторизации, которые можно обменять на токены доступа.

Обработка отзыва и истечения срока действия токенов обновления

Если ваше приложение запросило токен обновления для офлайн-доступа , вам также необходимо обработать его аннулирование или истечение срока действия. Токены могут быть аннулированы по разным причинам , например, из-за истечения срока их действия или из-за отзыва доступа пользователем или автоматизированным процессом. В этом случае тщательно продумайте реакцию вашего приложения, включая запрос пользователю при следующем входе в систему или очистку его данных. Чтобы получать уведомления об отзыве токенов, выполните интеграцию со службой Cross-Account Protection .

Использовать поэтапную авторизацию

Используйте инкрементную авторизацию для запроса соответствующих областей OAuth, когда эта функциональность необходима вашему приложению.

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

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

Например, ваше приложение может следовать этой модели:

1. Пользователь проходит аутентификацию в вашем приложении.
   1. Дополнительные области действия не требуются. Приложение предоставляет базовый функционал, позволяющий пользователю исследовать и использовать функции, не требующие дополнительных данных или доступа.
2. Пользователь выбирает функцию, требующую доступа к дополнительным данным
   1. Ваше приложение отправляет запрос на авторизацию для данной области OAuth, необходимой для этой функции. Если для этой функции требуется несколько областей, следуйте рекомендациям ниже .
   2. Если пользователь отклоняет запрос, приложение отключает функцию и предоставляет пользователю дополнительный контекст для повторного запроса доступа.

Обработка согласия для нескольких областей

При одновременном запросе нескольких областей действия пользователи могут не предоставить все запрошенные вами области действия OAuth. Ваше приложение должно обрабатывать отказы в доступе, отключая соответствующие функции.

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

Вы можете повторно запросить разрешение только после того, как пользователь чётко обозначит своё намерение использовать конкретную функцию, требующую разрешения. Ваше приложение должно предоставить пользователю соответствующий контекст и обоснование, прежде чем запрашивать разрешения OAuth.

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

Используйте безопасные браузеры

В веб-браузерах запросы на авторизацию OAuth 2.0 следует отправлять только из полнофункциональных веб-браузеров. На других платформах убедитесь, что выбран правильный тип клиента OAuth , и интегрируйте OAuth в соответствии с вашей платформой. Не перенаправляйте запросы через встроенные браузерные среды, включая веб-представления на мобильных платформах, например, WebView на Android или WKWebView на iOS. Вместо этого используйте собственные библиотеки OAuth или вход через Google для вашей платформы.

Ручное создание и настройка клиентов OAuth

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

Для автоматизированных рабочих процессов рассмотрите возможность использования учетных записей служб .

Удалить неиспользуемые клиенты OAuth

Регулярно проводите аудит своих клиентов OAuth 2.0 и заблаговременно удаляйте те, которые больше не требуются вашему приложению или устарели. Оставление неиспользуемых клиентов в настройках представляет потенциальную угрозу безопасности, поскольку клиент может быть использован не по назначению, если ваши учётные данные будут скомпрометированы.

Для дальнейшего снижения рисков, связанных с неиспользуемыми клиентами, клиенты OAuth 2.0, неактивные в течение шести месяцев, автоматически удаляются .

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