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