На этой странице рассматриваются некоторые общие рекомендации по интеграции с 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) для получения кодов авторизации, которые можно обменять на токены доступа.
Обработка отзыва и истечения срока действия токенов обновления
Если ваше приложение запросило токен обновления для доступа в автономном режиме , вы также должны обработать его аннулирование или истечение срока действия. Токены могут быть аннулированы по разным причинам , например, срок их действия мог истечь или доступ вашего приложения мог быть аннулирован пользователем или автоматизированным процессом. В этом случае тщательно продумайте, как должно реагировать ваше приложение, включая запрос пользователю при следующем входе в систему или очистку его данных. Чтобы получать уведомления об аннулировании токена, выполните интеграцию со службой Cross-Account Protection .
Использовать инкрементную авторизацию
Используйте инкрементную авторизацию для запроса соответствующих областей OAuth, когда эта функциональность необходима вашему приложению.
Не следует запрашивать доступ к данным при первой аутентификации пользователя, если только это не является необходимым для основных функций вашего приложения. Вместо этого запрашивайте только конкретные области, необходимые для задачи, следуя принципу выбора наименьших, наиболее ограниченных областей .
Всегда запрашивайте области действия в контексте, чтобы помочь пользователям понять, почему ваше приложение запрашивает доступ и как будут использоваться данные.
Например, ваше приложение может соответствовать следующей модели:
- Пользователь проходит аутентификацию в вашем приложении
- Никаких дополнительных областей не требуется. Приложение предоставляет базовую функциональность, позволяющую пользователю исследовать и использовать функции, не требующие дополнительных данных или доступа.
- Пользователь выбирает функцию, требующую доступа к дополнительным данным
- Ваше приложение делает запрос на авторизацию для этой конкретной области OAuth, требуемой для этой функции. Если эта функция требует несколько областей, следуйте рекомендациям ниже .
- Если пользователь отклоняет запрос, приложение отключает функцию и предоставляет пользователю дополнительный контекст для повторного запроса доступа.
Обработка согласия для нескольких областей
При запросе нескольких областей одновременно пользователи могут не предоставить все запрошенные вами области OAuth. Ваше приложение должно обрабатывать отказ в областях, отключая соответствующую функциональность.
Если базовая функциональность вашего приложения требует нескольких областей действия, объясните это пользователю, прежде чем запрашивать его согласие.
Вы можете снова запросить пользователя только после того, как он четко указал на намерение использовать конкретную функцию, требующую области действия. Ваше приложение должно предоставить пользователю соответствующий контекст и обоснование перед запросом областей действия OAuth.
Вам следует минимизировать количество областей, которые запрашивает ваше приложение одновременно. Вместо этого используйте инкрементальную авторизацию для запроса областей в контексте функций и возможностей.
Используйте безопасные браузеры
В Интернете запросы на авторизацию OAuth 2.0 должны быть сделаны только из полнофункциональных веб-браузеров. На других платформах убедитесь, что выбрали правильный тип клиента OAuth и интегрировали OAuth в соответствии с вашей платформой. Не перенаправляйте запрос через встроенные среды просмотра, включая веб-просмотры на мобильных платформах, таких как WebView на Android или WKWebView на iOS. Вместо этого используйте собственные библиотеки OAuth или Google Sign-in для вашей платформы.
Ручное создание и настройка клиентов OAuth
Чтобы предотвратить злоупотребления, клиенты OAuth не могут быть созданы или изменены программным путем. Вы должны использовать консоль разработчиков Google, чтобы явно подтвердить условия обслуживания, настроить свой клиент OAuth и подготовиться к проверке OAuth.
Для автоматизированных рабочих процессов рассмотрите возможность использования учетных записей служб .
Удалить неиспользуемые клиенты OAuth
Регулярно проводите аудит клиентов OAuth 2.0 и заблаговременно удаляйте тех, которые больше не требуются вашему приложению или устарели. Оставление неиспользуемых клиентов в конфигурации представляет потенциальную угрозу безопасности, поскольку клиент может быть использован не по назначению, если ваши учетные данные клиента когда-либо будут скомпрометированы.
Для дальнейшего снижения рисков, связанных с неиспользуемыми клиентами, клиенты OAuth 2.0, неактивные в течение шести месяцев, автоматически удаляются .
Рекомендуемая лучшая практика — не ждать автоматического удаления, а проактивно удалять неиспользуемых клиентов. Такая практика минимизирует поверхность атаки вашего приложения и обеспечивает хорошую гигиену безопасности.