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

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

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

Безопасная обработка пользовательских токенов

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

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

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

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

Токены с ограничением отправителя и DPoP

Чтобы защитить приложение от кражи токенов и атак повторного воспроизведения, рекомендуем ограничить отправителей токенов с помощью DPoP (Demonstrating Proof-of-Possession). Стандартные токены на предъявителя может использовать любой, кто их перехватит, а токены DPoP криптографически связаны с уникальной парой ключей, которая создается и хранится у клиента.

При использовании DPoP клиент предоставляет подтверждение (подписанный веб-токен JSON) конечной точке токена при запросе или обновлении токенов. Это подтверждает, что у клиента есть закрытый ключ, соответствующий открытому ключу, связанному с токеном. Если токен обновления, связанный с DPoP, будет украден, злоумышленник не сможет использовать его без закрытого ключа.

DPoP работает вместе с PKCE, обеспечивая комплексную защиту:

• PKCE защищает код авторизации во время первоначального перенаправления.
• DPoP защищает долгосрочный токен обновления, предотвращая атаки повторного воспроизведения в случае его компрометации.

Мы настоятельно рекомендуем использовать DPoP, если ваше приложение:

• Работает как установленное или десктопное приложение (или одностраничное приложение, сопряженное с сервером Backend-for-Frontend), в котором токены обновления могут быть более уязвимы для кражи.
• Оно получает доступ к особо конфиденциальным данным или ценным API, и утечка токена может привести к серьезным последствиям.
• Вам необходимо соблюдать строгие стандарты безопасности или соответствия, которые требуют использования токенов, ограниченных отправителем.

Подробные инструкции по созданию подтверждений DPoP и запросу токенов, связанных с DPoP, можно найти в руководстве по внедрению DPoP.

Используйте параметр state

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

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

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

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

Используйте пошаговую авторизацию

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

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

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

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

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

Как обрабатывать согласие для нескольких областей доступа

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

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

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

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

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

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

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

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

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

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

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

Чтобы снизить риски, связанные с неиспользуемыми клиентами, клиенты OAuth 2.0, которые были неактивны в течение шести месяцев, автоматически удаляются.

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