OAuth 2.0 для мобильных и компьютерных приложений

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

В этом документе объясняется, как приложения, установленные на таких устройствах, как телефоны, планшеты и компьютеры, используют конечные точки OAuth 2.0 от Google для авторизации доступа к YouTube Analytics API или YouTube Reporting API.

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

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

Этот процесс авторизации похож на тот, который используется для приложений веб-сервера. Основное отличие заключается в том, что установленные приложения должны открывать системный браузер и предоставлять локальный URI перенаправления для обработки ответов от сервера авторизации Google.

Библиотеки и примеры

Для приложений iOS мы рекомендуем использовать последнюю версию Sign In With Google iOS SDK. SDK обрабатывает авторизацию пользователей и проще в реализации, чем описанный в этом руководстве низкоуровневый протокол.

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

Требования

Как включить API для проекта

Любое приложение, вызывающее API Google, должно включить эти API в API Console.

Чтобы включить API для вашего проекта:

1. Откройте библиотеку API в Google API Console.
2. Выберите существующий проект или создайте новый.
3. Найдите и включите YouTube Analytics API и YouTube Reporting API на странице "Библиотека". Многие приложения, которые получают данные YouTube Аналитики, также взаимодействуют с YouTube Data API. Найдите и включите другие API, которые будут использоваться в вашем приложении.

Создайте учетные данные для авторизации

Любое приложение, которое использует OAuth 2.0 для доступа к API Google, должно иметь учетные данные для авторизации, которые идентифицируют приложение на сервере OAuth 2.0 Google. Ниже описано, как создать учетные данные для проекта. Затем ваши приложения смогут использовать эти учетные данные для доступа к API, которые вы включили для этого проекта.

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

iOS

1. Выберите тип приложения iOS.
2. Введите название клиента OAuth. Это название будет показываться на странице клиентов вашего проекта.
3. Введите идентификатор пакета приложения. Это значение ключа CFBundleIdentifier в файле со списком ресурсов приложения (info.plist). Обычно это значение отображается на панели General (Общие) или Signing & Capabilities (Подпись и возможности) в редакторе проектов Xcode. Идентификатор пакета также указан в разделе "Общая информация" на странице приложения на сайте Apple App Store Connect.

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

4. (Необязательно)

   Если приложение опубликовано в Apple App Store, введите его идентификатор в этом магазине. Идентификатор магазина – это числовая строка, которая есть в каждом URL в Apple App Store.

   1. Откройте приложение Apple App Store на устройстве iOS или iPadOS.
   2. Выполните поиск по названию своего приложения.
   3. Нажмите кнопку "Поделиться" (квадрат со стрелкой вверх).
   4. Выберите Копировать ссылку.
   5. Вставьте ссылку в текстовый редактор. Идентификатор магазина приложений – это последняя часть URL.

      Пример: https://apps.apple.com/app/google/id284815942

5. (Необязательно)

   Укажите идентификатор команды. Подробную информацию можно найти в разделе Как найти идентификатор команды документации по аккаунту разработчика Apple.

   Примечание. Поле "Идентификатор команды" обязательно, если вы включаете App Check для клиента.
6. (Необязательно)

   Включите проверку приложений для iOS. В этом случае сервис App Attest от Apple будет проверять, что запросы OAuth 2.0, поступающие от вашего клиента OAuth, подлинные и исходят из вашего приложения. Это помогает снизить риск имитации приложения. Подробнее о том, как включить App Check для приложения iOS…

7. Нажмите Создать.

UWP

1. Выберите тип приложения Universal Windows Platform.
2. Введите название клиента OAuth. Это название будет показываться в проекте для идентификации клиента.
3. Введите 12-значный идентификатор приложения в Microsoft Store. Это значение можно найти в Центре партнеров Microsoft на странице Идентификация приложения в разделе "Управление приложениями".
4. Нажмите Создать.

Для приложений UWP URI переадресации формируется с использованием уникального идентификатора безопасности пакета (SID) приложения. Package SID приложения можно найти в файле Package.appxmanifest в проекте Visual Studio.

При создании идентификатора клиента в консоли Google Cloud необходимо указать URI перенаправления в следующем формате, используя значение SID пакета в нижнем регистре:

ms-app://YOUR_APP_PACKAGE_SID

Примечание. Схема ms-app:// необходима для правильной работы перенаправления OAuth 2.0. Эта схема используется для активации протокола, который позволяет операционной системе запускать ваше приложение и передавать ответ авторизации от Google после того, как пользователь пройдет аутентификацию в браузере.

Для приложений UWP длина специальной схемы URI не может превышать 39 символов, как указано в документации Microsoft.

Определите области доступа

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

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

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

YouTube Analytics API использует следующие области действия:

Объем	Описание
https://www. googleapis. com/ auth/ youtube	Управляйте своим аккаунтом YouTube
https://www. googleapis. com/ auth/ youtube. readonly	Просмотреть свой аккаунт YouTube
https://www. googleapis. com/ auth/ youtubepartner	Просмотр и управление вашими активами и связанным с ними контентом на YouTube
https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly	Просмотр денежных и неденежных отчетов YouTube Analytics для вашего контента YouTube
https://www. googleapis. com/ auth/ yt-analytics. readonly	Просмотр отчетов YouTube Analytics для вашего контента на YouTube

YouTube Reporting API использует следующие области действия:

Объем	Описание
https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly	Просмотр денежных и неденежных отчетов YouTube Analytics для вашего контента YouTube
https://www. googleapis. com/ auth/ yt-analytics. readonly	Просмотр отчетов YouTube Analytics для вашего контента на YouTube

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

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

Получение токенов доступа OAuth 2.0

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

Шаг 1. Сгенерируйте верификатор кода и запрос

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

Создайте верификатор кода

code_verifier – это криптографическая случайная строка с высокой энтропией, в которой используются незарезервированные символы [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~". Минимальная длина строки – 43 символа, максимальная – 128.

У верификатора кода должно быть достаточно энтропии, чтобы его значение было сложно угадать.

Создайте код для подтверждения

Поддерживается два метода создания кода.

Методы генерации кода вызова
S256 (рекомендуется)	Код вызова – это хеш SHA256 верификатора кода, закодированный по стандарту Base64 для URL (без заполнения). code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain	Код запроса совпадает со значением кода подтверждения, сгенерированного выше. code_challenge = code_verifier

Шаг 2. Отправьте запрос на сервер OAuth 2.0 Google

Чтобы получить разрешение пользователя, отправьте запрос на сервер авторизации Google по адресу https://accounts.google.com/o/oauth2/v2/auth. Этот конечный адрес используется для поиска активного сеанса, аутентификации пользователя и получения его согласия. Конечная точка доступна только через SSL и отклоняет подключения HTTP (без SSL).

Сервер авторизации поддерживает следующие параметры строки запроса для установленных приложений:

Параметры
client_id	Обязательно Идентификатор клиента для вашего приложения. Это значение можно найти на странице клиентов в Cloud Console.
redirect_uri	Обязательно Определяет, как сервер авторизации Google отправляет ответ вашему приложению. Для установленных приложений доступно несколько вариантов переадресации, и вы должны настроить учетные данные для авторизации с учетом определенного метода переадресации. Значение должно точно совпадать с одним из авторизованных URI перенаправления для клиента OAuth 2.0, который вы настроили на странице клиентов в Cloud Console. Если это значение не соответствует авторизованному URI, вы получите ошибку redirect_uri_mismatch. В таблице ниже приведены значения параметра redirect_uri для каждого метода. Значения атрибута redirect_uri Специальная схема URI com.example.app:redirect_uri_path или com.googleusercontent.apps.123:redirect_uri_path com.example.app – это обратная запись DNS домена, который находится под вашим контролем. Чтобы пользовательская схема была действительной, она должна содержать точку. com.googleusercontent.apps.123 – обратная запись DNS идентификатора клиента. redirect_uri_path – необязательный компонент пути, например /oauth2redirect. Обратите внимание, что путь должен начинаться с одной косой черты, в отличие от обычных URL с протоколом HTTP. Примечание. Пользовательские схемы URI больше не поддерживаются в приложениях для Android и Chrome. Подробнее об альтернативах пользовательским схемам… IP-адрес loopback-интерфейса http://127.0.0.1:port или http://[::1]:port Запросите у платформы соответствующий IP-адрес обратной связи и запустите прослушиватель HTTP на случайном доступном порте. Замените port на номер порта, который использует ваше приложение. Обратите внимание, что поддержка перенаправления на IP-адрес обратной связи в мобильных приложениях ПРЕКРАЩЕНА.
response_type	Обязательно Определяет, возвращает ли конечная точка Google OAuth 2.0 код авторизации. Установите для параметра значение code для установленных приложений.
scope	Обязательно Список областей действия, разделенных пробелами, которые определяют ресурсы, к которым ваше приложение может получить доступ от имени пользователя. Эти значения используются в окне запроса согласия, которое Google показывает пользователю. Области действия позволяют приложению запрашивать доступ только к тем ресурсам, которые ему нужны, а пользователям – контролировать объем доступа, который они предоставляют приложению. Таким образом, между количеством запрошенных областей и вероятностью получения согласия пользователя существует обратная зависимость. YouTube Analytics API использует следующие области действия: Объем Описание https://www. googleapis. com/ auth/ youtube Управляйте своим аккаунтом YouTube https://www. googleapis. com/ auth/ youtube. readonly Просмотреть свой аккаунт YouTube https://www. googleapis. com/ auth/ youtubepartner Просмотр и управление вашими активами и связанным с ними контентом на YouTube https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly Просмотр денежных и неденежных отчетов YouTube Analytics для вашего контента YouTube https://www. googleapis. com/ auth/ yt-analytics. readonly Просмотр отчетов YouTube Analytics для вашего контента на YouTube YouTube Reporting API использует следующие области действия: Объем Описание https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly Просмотр денежных и неденежных отчетов YouTube Analytics для вашего контента YouTube https://www. googleapis. com/ auth/ yt-analytics. readonly Просмотр отчетов YouTube Analytics для вашего контента на YouTube В документе Области действия API OAuth 2.0 приведен полный список областей действия, которые можно использовать для доступа к API Google.
code_challenge	Рекомендуется Указывает закодированный code_verifier, который будет использоваться в качестве запроса на стороне сервера при обмене кода авторизации. Подробнее о том, как создать код-вызов…
code_challenge_method	Рекомендуется Указывает, какой метод использовался для кодирования code_verifier, который будет использоваться при обмене кодами авторизации. Этот параметр необходимо использовать вместе с параметром code_challenge. Если в запросе, содержащем code_challenge, нет значения code_challenge_method, по умолчанию используется plain. Допустимые значения: S256 (да) и plain (нет).
state	Рекомендуется Любое строковое значение, которое ваше приложение использует для сохранения состояния между запросом авторизации и ответом сервера авторизации. Сервер возвращает точное значение, которое вы отправляете в виде пары name=value в идентификаторе фрагмента URL (#) в redirect_uri после того, как пользователь разрешит или запретит вашему приложению доступ. Этот параметр можно использовать для разных целей, например чтобы направлять пользователя к нужному ресурсу в приложении, отправлять одноразовые коды и предотвращать подделку межсайтовых запросов. Поскольку redirect_uri можно подобрать, использование значения state повышает вероятность того, что входящее подключение является результатом запроса на аутентификацию. Если вы сгенерируете случайную строку или закодируете хеш файла cookie или другого значения, которое фиксирует состояние клиента, вы сможете проверить ответ, чтобы дополнительно убедиться, что запрос и ответ поступили из одного и того же браузера. Это обеспечит защиту от таких атак, как межсайтовая подделка запроса. Пример того, как создать и подтвердить токен state, можно найти в документации по OpenID Connect. Важно! Клиент OAuth должен предотвращать CSRF, как указано в спецификации OAuth2 . Один из способов сделать это – использовать параметр state, чтобы поддерживать состояние между запросом авторизации и ответом сервера авторизации.
login_hint	Необязательно Если приложение знает, какой пользователь пытается выполнить аутентификацию, оно может использовать этот параметр, чтобы предоставить подсказку серверу аутентификации Google. Сервер использует подсказку, чтобы упростить процесс входа, заполнив поле адреса электронной почты в форме входа или выбрав соответствующий сеанс с несколькими входами. В качестве значения параметра укажите адрес электронной почты или идентификатор sub, который соответствует идентификатору Google пользователя.

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

Примеры URL авторизации

На вкладках ниже приведены примеры URL авторизации для разных вариантов URI переадресации.

Каждый URL запрашивает доступ к области, которая позволяет получать отчеты YouTube Аналитики пользователя.

URL идентичны, за исключением значения параметра redirect_uri. URL также содержат обязательные параметры response_type и client_id, а также необязательный параметр state. Каждый URL содержит разрывы строк и пробелы для удобства чтения.

Специальная схема URI

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

IP-адрес обратной связи

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Шаг 3. Google запрашивает согласие пользователя

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

На этом этапе вашему приложению не нужно ничего делать, пока оно ожидает ответа от сервера OAuth 2.0 Google, указывающего, был ли предоставлен доступ. Этот ответ описан на следующем шаге.

Ошибки

Запросы к конечной точке авторизации OAuth 2.0 от Google могут приводить к показу пользовательских сообщений об ошибках вместо ожидаемых процессов аутентификации и авторизации. Распространенные коды ошибок и способы их устранения:

admin_policy_enforced

Аккаунт Google не может авторизовать одну или несколько запрошенных областей действия из-за правил, установленных администратором Google Workspace. В справочной статье Справочного центра Google Workspace для администраторов Как управлять доступом сторонних и внутренних приложений к данным Google Workspace приведена информация о том, как администратор может ограничить доступ ко всем областям действия или к областям действия с конфиденциальными и ограниченными данными, пока не будет явно предоставлен доступ к идентификатору клиента OAuth.

disallowed_useragent

Конечная точка авторизации отображается во встроенном агенте пользователя, запрещенном правилами OAuth 2.0 Google.

Разработчики iOS и macOS могут столкнуться с этой ошибкой при открытии запросов на авторизацию в WKWebView. Вместо этого разработчикам следует использовать библиотеки iOS, такие как вход с аккаунтом Google для iOS или AppAuth для iOS от OpenID Foundation.

Веб-разработчики могут столкнуться с этой ошибкой, когда приложение для iOS или macOS открывает общую веб-ссылку во встроенном агенте пользователя и пользователь переходит к конечной точке авторизации OAuth 2.0 Google с вашего сайта. Разработчики должны разрешить открывать общие ссылки в обработчике ссылок по умолчанию операционной системы, который включает как обработчики универсальных ссылок, так и браузер по умолчанию. Также поддерживается библиотека SFSafariViewController.

org_internal

Идентификатор клиента OAuth в запросе относится к проекту, который ограничивает доступ к аккаунтам Google в определенной организации Google Cloud. Подробную информацию об этом параметре конфигурации можно найти в разделе Тип пользователя справочной статьи "Как настроить окно запроса доступа OAuth".

deleted_client

Клиент OAuth, используемый для выполнения запроса, был удален. Удаление может быть выполнено вручную или автоматически в случае неиспользуемых клиентов . Удаленных клиентов можно восстановить в течение 30 дней после удаления. Подробнее…

invalid_grant

Если вы используете верификатор кода и запрос, параметр code_callenge недействителен или отсутствует. Убедитесь, что параметр code_challenge задан правильно.

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

redirect_uri_mismatch

Параметр redirect_uri, переданный в запросе на авторизацию, не соответствует авторизованному URI переадресации для идентификатора клиента OAuth. Проверьте авторизованные URI перенаправления на странице клиентов в консоли Google Cloud.

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

Параметр redirect_uri может относиться к устаревшему и больше не поддерживаемому потоку OAuth вне диапазона (OOB). Чтобы обновить интеграцию, следуйте инструкциям в руководстве по переносу.

invalid_request

При обработке запроса произошла ошибка. Это может быть связано со следующими причинами:

• Неправильный формат запроса
• В запросе отсутствовали обязательные параметры
• В запросе используется способ авторизации, который не поддерживается Google. Проверьте, что при интеграции OAuth используется рекомендуемый метод
• Для URI переадресации использована неподдерживаемая специальная схема. Если вы видите сообщение об ошибке Пользовательская схема URI не поддерживается в приложениях для Android и Chrome, ознакомьтесь с альтернативными вариантами.

Шаг 4. Обработайте ответ сервера OAuth 2.0

Способ получения ответа на запрос авторизации зависит от схемы URI переадресации, используемой приложением. Независимо от схемы ответ будет содержать код авторизации (code) или ошибку (error). Например, error=access_denied означает, что пользователь отклонил запрос.

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

Шаг 5. Обменяйте код авторизации на токены обновления и доступа

Чтобы обменять код авторизации на токен доступа, вызовите конечную точку https://oauth2.googleapis.com/token и задайте следующие параметры:

Поля
client_id	Идентификатор клиента, полученный на странице клиентов Cloud Console.
client_secret	Необязательно Секретный код клиента, полученный на странице клиентов в Cloud Console.
code	Код авторизации, возвращенный в ответ на первоначальный запрос.
code_verifier	Проверочный код, созданный на шаге 1.
grant_type	Согласно спецификации OAuth 2.0, значение этого поля должно быть равно authorization_code.
redirect_uri	Один из URI переадресации, указанных для вашего проекта на странице клиентов в Cloud Console для client_id.

Использование DPoP не обязательно, но рекомендуется для повышения уровня безопасности. Безопасность DPoP зависит от того, ограничен ли закрытый ключ одним устройством. Мы рекомендуем хранить его так, чтобы его нельзя было скопировать с устройства, например с помощью TPM, Secure Enclave или других аппаратных хранилищ ключей. Чтобы использовать DPoP, ваше приложение должно генерировать новый уникальный токен JWT для подтверждения DPoP для каждого запроса к конечной точке токена и добавлять его в качестве заголовка HTTP-запроса.

Заголовок	Обязательно	Описание
DPoP	Необязательно	Доказательство DPoP – это токен JWT, который подтверждает владение закрытым ключом. Это заголовок, а не параметр. Если он указан, возвращаемые токены будут привязаны к этому ключу. Для каждого запроса необходимо генерировать новое уникальное подтверждение, которое должно включать утверждения htm (метод HTTP) и htu (URI HTTP), соответствующие запросу.

Ниже приведен пример запроса.

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Как создать доказательство DPoP

Ниже описано, как создать подтверждение DPoP с помощью OpenSSL в командной строке.

1. Создайте пару ключей EC P-256:

   openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
   openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

2. Создайте заголовок DPoP:

   Заголовок должен содержать утверждения typ, alg и jwk (открытый ключ). Значения x и y – это закодированные в Base64Url координаты вашего открытого ключа EC. Закодируйте этот JSON-код с помощью Base64Url:

   {
     "typ":"dpop+jwt",
     "alg":"ES256",
     "jwk": {
       "kty":"EC",
       "x":"YOUR_PUBLIC_KEY_X",
       "y":"YOUR_PUBLIC_KEY_Y",
       "crv":"P-256"
     }
   }

3. Создайте полезную нагрузку DPoP:

   Полезная нагрузка должна включать jti (уникальный идентификатор запроса), htm (метод HTTP, например POST), htu (URI HTTP, например https://oauth2.googleapis.com/token) и iat (время выдачи). Если вы получили одноразовый код от сервера в заголовке DPoP-Nonce в ответе на предыдущий запрос, вы должны включить это значение одноразового кода в утверждение nonce. Заявление nonce является необязательным для обмена кода авторизации и используется только в том случае, если ранее был получен заголовок DPoP-Nonce. Закодируйте этот JSON-код с помощью Base64Url:

   {
     "jti":"JTI_VALUE",
     "htm":"POST",
     "htu":"https://oauth2.googleapis.com/token",
     "iat":YOUR_JWT_ISSUED_TIME,
     "nonce":"SERVER_PROVIDED_NONCE"
   }

   Значение jti зависит от типа биржи:

   • Для обмена кодами авторизации значение jti должно быть хешем SHA256 кода авторизации, закодированным по стандарту Base64 для URL: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
   • Для обмена токенами обновления параметр jti должен быть уникальным идентификатором для каждого запроса: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
4. Подпишите доказательство.

   Объедините закодированный заголовок и полезную нагрузку с помощью точки (.), а затем подпишите результат с помощью закрытого ключа, используя алгоритм ES256. Обратите внимание, что JWS требует, чтобы подпись была в необработанном объединенном формате R | S (64 байта для P-256). Если вы используете OpenSSL напрямую, вам нужно преобразовать подпись, закодированную по умолчанию в формате ASN.1 DER, в этот необработанный формат.

Успешный обмен подтверждается ответом 200 OK, содержащим токены. Если при обмене используется действительное подтверждение DPoP, токен обновления, возвращаемый Google, будет привязан к вашему ключу с помощью DPoP, а токены доступа – нет. Токены доступа сохранят token_type Bearer вместо DPoP. Кроме того, Google возвращает в ответе HTTP-заголовок DPoP-Nonce. Клиент должен кешировать этот nonce и включать его в утверждение nonce подтверждения DPoP в последующих запросах (например, при обмене токена обновления на новый токен доступа или при вызове API, защищенных DPoP). Используя этот одноразовый код, вы можете избежать дополнительной ошибки (use_dpop_nonce) при следующем запросе.

Доказательства DPoP должны быть включены в запросы на обмен токенов, созданные с помощью токенов обновления, связанных с DPoP.

Сбой обмена происходит, если заголовок DPoP отсутствует, когда он ожидается, недействителен или если в подтверждении используется ключ, отличный от того, который привязан к токену. В таких случаях сервер возвращает ошибку 400 Bad Request. Если в подтверждении DPoP есть несовпадающие утверждения htm или htu, просроченное утверждение iat, повторно использованное утверждение jti или недействительная подпись, Google возвращает код ошибки invalid_dpop_proof. Если требуется одноразовый код DPoP, например при обмене токена обновления, а в подтверждении DPoP отсутствует утверждение nonce или значение одноразового кода неприемлемо для сервера (например, срок его действия истек, он уже использовался или неверен), Google возвращает код ошибки use_dpop_nonce вместе с HTTP-заголовком DPoP-Nonce, содержащим новый одноразовый код, который можно использовать в последующем запросе. В других случаях может возвращаться значение invalid_grant.

В ответ на этот запрос Google возвращает объект JSON, содержащий токен доступа с ограниченным сроком действия и токен обновления.

Ответ содержит следующие поля:

Поля
access_token	Токен, который приложение отправляет для авторизации запроса к API Google.
expires_in	Оставшееся время действия токена доступа в секундах.
id_token	Примечание. Это свойство возвращается, только если запрос включает область идентификации, например openid, profile или email. Значение представляет собой веб-токен JSON (JWT), который содержит информацию о пользователе с цифровой подписью.
refresh_token	Токен, который можно использовать для получения нового токена доступа. Токены обновления действительны, пока пользователь не отзовет доступ или не истечет срок действия токена обновления. Если использовался DPoP, токен обновления привязывается к закрытому ключу, который использовался для подписи подтверждения DPoP. Обратите внимание, что для установленных приложений всегда возвращаются токены обновления.
refresh_token_expires_in	Оставшийся срок действия токена обновления в секундах. Это значение задается только в том случае, если пользователь предоставляет временный доступ.
scope	Области действия, предоставленные access_token, в виде списка строк, разделенных пробелами и с учетом регистра.
token_type	Тип возвращенного токена. Это значение всегда равно Bearer, даже если используется DPoP.

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

Ниже приведен пример заголовков и тела успешного ответа при использовании DPoP:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

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

Шаг 6. Проверьте, какие области действия разрешили пользователи

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

Однако из этого правила бывают исключения. Приложения Google Workspace Enterprise с делегированием доступа к данным в домене или приложения, помеченные как надежные, обходят окно запроса доступа с детализированными разрешениями. Для таких приложений пользователи не увидят окно запроса доступа с детализированными разрешениями. Вместо этого приложение получит либо все запрошенные области действия, либо ни одной.

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

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

Например, в следующем примере ответа на запрос токена доступа указано, что пользователь предоставил вашему приложению доступ к разрешениям на чтение активности на Диске и мероприятий в Календаре:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Вызов API Google

После того как ваше приложение получит токен доступа, вы можете использовать его для вызовов Google API от имени определенного аккаунта пользователя, если предоставлены необходимые для API области доступа. Для этого включите токен доступа в запрос к API, добавив параметр запроса access_token или значение заголовка HTTP Authorization Bearer. По возможности лучше использовать заголовок HTTP, поскольку строки запроса обычно видны в журналах сервера. В большинстве случаев для настройки вызовов API Google (например, вызовов YouTube Analytics API) можно использовать клиентскую библиотеку.

Обратите внимание, что YouTube Analytics API не поддерживает сервисные аккаунты. YouTube Reporting API поддерживает сервисные аккаунты только для владельцев контента, которым принадлежит несколько каналов YouTube, например для звукозаписывающих компаний и киностудий.

Вы можете попробовать все API Google и посмотреть их области действия в OAuth 2.0 Playground.

Примеры HTTP GET

Запрос к конечной точке reports.query (YouTube Analytics API) с использованием заголовка HTTP Authorization: Bearer может выглядеть следующим образом: Обратите внимание, что вам нужно указать собственный токен доступа:

GET /youtube/v2/reports?ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Вот пример вызова того же API для аутентифицированного пользователя с помощью параметра строки запроса access_token:

GET https://www.googleapis.com/youtube/v2/reports?access_token=access_token&ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

Примеры использования оператора curl

Вы можете протестировать эти команды с помощью приложения командной строки curl. Вот пример с использованием заголовка HTTP (рекомендуемый вариант):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v2/reports?ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

Или параметр строки запроса:

curl https://www.googleapis.com/youtube/v2/reports?access_token=access_token&ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

Как обновить токен доступа

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

Чтобы обновить токен доступа, приложение отправляет HTTPS-запрос POST на сервер авторизации Google (https://oauth2.googleapis.com/token), который включает следующие параметры в теле запроса:

Название	Значение
client_id	Идентификатор клиента, полученный из API Console.
client_secret	Необязательно Секретный код клиента, полученный из API Console. (Параметр client_secret неприменим к запросам от клиентов, зарегистрированных как приложения для Android, iOS или Chrome.)
grant_type	В соответствии со спецификацией OAuth 2.0 в этом поле должно быть указано значение refresh_token.
refresh_token	Маркер обновления, возвращенный при обмене кода авторизации.

Использовать DPoP необязательно, но рекомендуется для повышения безопасности. Чтобы использовать DPoP с токеном обновления, ваше приложение должно генерировать новый уникальный JWT-токен подтверждения DPoP для каждого запроса к конечной точке токена. Это подтверждение должно быть подписано тем же закрытым ключом, который использовался при первоначальном обмене кодами авторизации. Приложение добавляет подтверждение в качестве заголовка HTTP-запроса.

Заголовок	Обязательно	Описание
DPoP	Необязательно	Доказательство DPoP – это токен JWT, который подтверждает владение закрытым ключом. Это заголовок, а не параметр. Если он указан, возвращаемые токены привязываются к этому ключу. Для каждого запроса необходимо генерировать новое уникальное подтверждение, которое должно включать утверждения htm (метод HTTP) и htu (URI HTTP), соответствующие запросу.

Ниже приведен пример запроса.

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: DPOP_PROOF_JWT

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

Чтобы использовать DPoP с токеном обновления, необходимо сгенерировать новый уникальный JWT-токен подтверждения DPoP для запроса. Пошаговые инструкции по созданию пары ключей и JWT приведены в разделе Как создать подтверждение DPoP.

Успешный обмен обозначается ответом 200 OK, содержащим новый токен доступа. Если используется DPoP, значение параметра token_type – Bearer. Успешный ответ подтверждает, что доказательство DPoP для токена обновления было принято. Google также может вернуть в ответе новый HTTP-заголовок DPoP-Nonce. В этом случае ваш клиент должен кешировать этот одноразовый код и включать его в утверждение nonce подтверждения DPoP в последующих запросах.

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

Ниже приведен пример заголовков и тела успешного ответа при использовании DPoP.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Обратите внимание, что количество токенов обновления, которые будут выданы, ограничено. Одно ограничение действует для сочетания клиент/пользователь, а другое – для пользователя во всех клиентах. Токены обновления следует сохранять в долговременном хранилище и использовать, пока они действительны. Если ваше приложение запрашивает слишком много токенов обновления, оно может столкнуться с этими ограничениями, и в этом случае старые токены обновления перестанут работать.

Отзыв токена

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

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

Чтобы отозвать токен программно, приложение отправляет запрос на адрес https://oauth2.googleapis.com/revoke и включает токен в качестве параметра:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

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

Если отзыв успешно обработан, то код статуса HTTP ответа – 200. В случае ошибки возвращается код статуса HTTP 400 и код ошибки.

Важно! При отзыве удаляются все области действия OAuth 2.0, ранее предоставленные проекту, и аннулируются все выданные токены доступа или токены обновления для всех клиентов, зарегистрированных в этом проекте.

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

Методы перенаправления в приложение

Специальная схема URI

Специальные схемы URI – это ссылки на контент, которые используют специальную схему для открытия приложения.

Важно! Специальные схемы URI больше не поддерживаются из-за риска имитации приложений.

Альтернатива пользовательским схемам URI в приложениях Chrome

Используйте Chrome Identity API, который передает ответ OAuth 2.0 непосредственно в приложение, устраняя необходимость в URI перенаправления.

IP-адрес обратной связи (macOS, Linux, Windows)

Важно! Вариант перенаправления на IP-адрес замыкания на себя УСТАРЕЛ для типов клиентов OAuth Android, приложение Chrome и iOS. Чтобы узнать, как перейти на поддерживаемый альтернативный метод, ознакомьтесь с руководством по переходу на метод замыкания IP-адреса на себя.

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

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

Рекомендуемое использование	Приложения для macOS, Linux и Windows (кроме приложений для универсальной платформы Windows).
Значения форм	Выберите тип приложения Компьютерное приложение.

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

Копирование и вставка вручную (поддержка прекращена)

Важно! Копирование и вставка вручную, также известные как метод перенаправления вне диапазона (OOB), больше не поддерживаются. Ознакомьтесь с руководством по переходу с OOB, чтобы узнать, как перейти на безопасную альтернативу.

Защитите свои приложения

Как подтвердить право собственности на приложение для Chrome

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

Для подтверждения вам понадобится аккаунт разработчика в интернет-магазине Chrome. Чтобы успешно пройти проверку, необходимо выполнить следующие требования:

• В Личном кабинете разработчика продуктов для интернет-магазина Chrome должен быть зарегистрирован продукт с тем же идентификатором товара, что и у клиента OAuth расширения Chrome, для которого вы проходите проверку.
• Вы должны быть издателем продукта в интернет-магазине Chrome. Подробнее об управлении доступом в личном кабинете разработчика продуктов для интернет-магазина Chrome…

В разделе Verify App Ownership (Подтверждение права собственности на приложение) клиента расширения Chrome нажмите кнопку Verify Ownership (Подтвердить право собственности), чтобы завершить процесс проверки.

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

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

Чтобы устранить проблему, попробуйте сделать следующее:

• Убедитесь, что в Личном кабинете разработчика продуктов для интернет-магазина Chrome зарегистрирован продукт с тем же идентификатором, что и у OAuth-клиента расширения Chrome, для которого вы проходите проверку.
• Убедитесь, что вы являетесь издателем приложения, то есть его индивидуальным издателем или участником издательской группы. Подробнее об управлении доступом в Личном кабинете разработчика продуктов для интернет-магазина Chrome…
• Если вы только что обновили список издателей группы, убедитесь, что список участников группы издателей синхронизирован в Личном кабинете разработчика продуктов для интернет-магазина Chrome. Подробнее о том, как синхронизировать список спонсоров…

App Check (только для iOS)

Функция App Check помогает защитить приложения для iOS от несанкционированного использования. Она проверяет, исходят ли запросы к конечным точкам Google OAuth 2.0 из ваших приложений, с помощью сервиса App Attest от Apple. Это помогает снизить риск имитации приложения.

Как включить проверку приложений для клиента iOS

Чтобы успешно включить App Check для клиента iOS, необходимо выполнить следующие требования:

• Укажите идентификатор команды для клиента iOS.
• В идентификаторе пакета нельзя использовать подстановочные знаки, поскольку он может относиться к нескольким приложениям. Это означает, что идентификатор пакета не должен содержать символ звездочки (*).

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

Чтобы включить проверку приложений, активируйте переключатель Защитите свой клиент OAuth от злоупотреблений с помощью Firebase App Check в режиме редактирования клиента iOS.

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

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

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

Как включить проверку приложений для клиента iOS

Включение Проверки приложений не приводит к автоматической блокировке нераспознанных запросов. Чтобы включить эту защиту, перейдите в режим редактирования клиента iOS. Показатели проверки приложений будут в правой части страницы в разделе Google Identity для iOS. Показатели включают следующую информацию:

• Количество проверенных запросов – запросы с действительным токеном App Check. После того как вы включите принудительное применение App Check, будут выполняться только запросы из этой категории.
• Количество непроверенных запросов: вероятно, устаревшие запросы клиентов – запросы, в которых отсутствует токен Проверки приложений. Они могут поступать из более старой версии приложения, в которой не реализована Проверка приложений.
• Количество неподтвержденных запросов: запросы из неизвестных источников – запросы без токена проверки приложений, которые, по всей видимости, поступают не из вашего приложения.
• Количество неподтвержденных запросов: недействительные запросы – запросы с недействительным токеном App Check, которые могут быть отправлены с поддельного клиента, пытающегося выдать себя за ваше приложение, или из эмулируемой среды.

Изучите эти показатели, чтобы понять, как принудительное использование App Check повлияет на ваших пользователей.

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

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

Как отключить проверку приложений для клиента iOS

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

Чтобы отменить принудительное использование App Check для клиента iOS, перейдите в режим редактирования клиента iOS, нажмите кнопку UNENFORCE (Отменить принудительное использование) и подтвердите свой выбор.

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

Как отключить проверку приложений для клиента iOS

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

Чтобы отключить App Check для клиента iOS, перейдите в режим редактирования клиента iOS и отключите переключатель Защитите клиента OAuth от злоупотреблений с помощью Firebase App Check.

Примечание. После отключения проверки приложений изменения вступят в силу в течение 15 минут.

Доступ на основе времени

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

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

Дополнительные ресурсы

Многие из приведенных здесь рекомендаций основаны на документе IETF Best Current Practice OAuth 2.0 for Native Apps.

Как включить защиту связанных аккаунтов

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

Вот несколько примеров типов событий, которые сервис защиты связанных аккаунтов Google отправляет в ваше приложение:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

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