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

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

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

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

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

Альтернативы

Для мобильных приложений вы можете предпочесть использовать Google Sign-in для Android или iOS . Клиентские библиотеки Google Sign-in обрабатывают аутентификацию и авторизацию пользователей, и их может быть проще реализовать, чем описанный здесь протокол более низкого уровня.

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

Библиотеки и образцы

Мы рекомендуем следующие библиотеки и примеры, которые помогут вам реализовать процесс OAuth 2.0, описанный в этом документе:

Предпосылки

Включите API для вашего проекта

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

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

  1. Open the API Library в Google API Console.
  2. If prompted, select a project, or create a new one.
  3. В API Library перечислены все доступные API, сгруппированные по семейству продуктов и популярности. Если API, который вы хотите включить, не отображается в списке, используйте поиск, чтобы найти его, или нажмите « Просмотреть все » в семействе продуктов, к которому он принадлежит.
  4. Выберите API, который вы хотите включить, затем нажмите кнопку « Включить ».
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

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

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

  1. Go to the Credentials page.
  2. Щелкните Создать учетные данные > Идентификатор клиента OAuth .
  3. В разделах ниже описаны типы клиентов и методы перенаправления, поддерживаемые сервером авторизации Google. Выберите тип клиента, рекомендуемый для вашего приложения, назовите ваш клиент OAuth и задайте другие поля в форме по мере необходимости.

Пользовательская схема URI (Android, iOS, UWP)

Настраиваемая схема URI рекомендуется для приложений Android, приложений iOS и приложений универсальной платформы Windows (UWP).

Андроид
  1. Выберите тип приложения Android .
  2. Введите имя клиента OAuth. Это имя отображается в Credentials page вашего проекта для идентификации клиента.
  3. Введите имя пакета вашего приложения для Android. Это значение определяется в атрибуте package элемента <manifest> в файле манифеста приложения.
  4. Введите отпечаток сертификата подписи SHA-1 дистрибутива приложения.
    • Если в вашем приложении используется подпись приложения в Google Play , скопируйте отпечаток SHA-1 со страницы подписи приложения в Play Console.
    • Если вы управляете собственным хранилищем ключей и ключами подписи, используйте утилиту keytool , входящую в состав Java, для печати информации о сертификате в удобочитаемом формате. Скопируйте значение SHA1 в разделе Certificate fingerprints выходных данных keytool . Дополнительные сведения см. в разделе Аутентификация вашего клиента в документации по API Google для Android.
  5. Щелкните Создать .
iOS
  1. Выберите тип приложения iOS .
  2. Введите имя клиента OAuth. Это имя отображается в Credentials page вашего проекта для идентификации клиента.
  3. Введите идентификатор пакета для вашего приложения. Идентификатор пакета — это значение ключа CFBundleIdentifier в файле ресурсов списка информационных свойств вашего приложения ( info.plist ). Это значение чаще всего отображается на панели «Общие» или на панели «Подписание и возможности» редактора проекта Xcode. Идентификатор пакета также отображается в разделе «Общая информация» на странице «Информация о приложении» для приложения на сайте Apple App Store Connect .
  4. (По желанию)

    Введите идентификатор вашего приложения в магазине приложений, если приложение опубликовано в магазине приложений Apple. Идентификатор магазина — это числовая строка, включенная в каждый URL-адрес Apple App Store.

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

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

  5. (По желанию)

    Введите идентификатор вашей команды. Дополнительную информацию см. в разделе « Нахождение идентификатора вашей команды» в документации по учетной записи разработчика Apple.

  6. Щелкните Создать .
UWP
  1. Выберите тип приложения универсальной платформы Windows .
  2. Введите имя клиента OAuth. Это имя отображается в Credentials page вашего проекта для идентификации клиента.
  3. Введите 12-значный идентификатор Microsoft Store вашего приложения. Это значение можно найти в Microsoft Partner Center на странице удостоверения приложения в разделе Управление приложениями.
  4. Щелкните Создать .

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

IP-адрес замыкания на себя (macOS, Linux, рабочий стол Windows)

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

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

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

Ручное копирование/вставка

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

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

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

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

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

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

Шаг 1. Создайте верификатор кода и вызов

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

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

code_verifier — это криптографическая случайная строка с высокой энтропией, использующая незарезервированные символы [AZ] / [az] / [0-9] / "-" / "." / "_" / "~", с минимальной длиной 43 символа и максимальной длиной 128 символов.

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

Создайте вызов кода

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

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

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

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

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

Параметры
client_id Необходимый

Идентификатор клиента для вашего приложения. Вы можете найти это значение в API ConsoleCredentials page.

redirect_uri Необходимый

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

Значение должно точно совпадать с одним из авторизованных URI перенаправления для клиента OAuth 2.0, который вы настроили в API ConsoleCredentials page. Если это значение не соответствует авторизованному 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.
петлевой IP-адрес http://127.0.0.1: port или http://[::1]: port

Запросите на своей платформе соответствующий петлевой IP-адрес и запустите прослушиватель HTTP на произвольном доступном порту. Замените port фактическим номером порта, который слушает ваше приложение.

Обратите внимание, что поддержка параметра перенаправления IP-адреса по шлейфу в мобильных приложениях УСТАРЕЛА .

response_type Необходимый

Определяет, возвращает ли конечная точка Google OAuth 2.0 код авторизации.

Задайте для параметра значение code для установленных приложений.

scope Необходимый

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

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

code_challenge рекомендуемые

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

code_challenge_method рекомендуемые

Указывает, какой метод использовался для кодирования code_verifier , который будет использоваться при обмене кодом авторизации. Этот параметр должен использоваться с параметром code_challenge , описанным выше. Значение code_challenge_method по умолчанию равно plain , если оно отсутствует в запросе, включающем code_challenge . Единственными поддерживаемыми значениями для этого параметра являются S256 или plain .

state рекомендуемые

Указывает любое строковое значение, которое ваше приложение использует для поддержания состояния между вашим запросом авторизации и ответом сервера авторизации. Сервер возвращает точное значение, которое вы отправляете в виде пары name=value в идентификаторе фрагмента URL-адреса ( # ) redirect_uri после того, как пользователь соглашается или отклоняет запрос доступа вашего приложения.

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

login_hint По желанию

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

Задайте в качестве значения параметра адрес электронной почты или sub идентификатор, который эквивалентен идентификатору Google ID пользователя.

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

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

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

Пользовательская схема URI

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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=email%20profile&
 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, для доступа к которым запрашивается разрешение с учетными данными пользователя, а также сводка областей доступа, которые должны быть предоставлены. Затем пользователь может дать согласие на предоставление доступа к одной или нескольким областям, запрошенным вашим приложением, или отклонить запрос.

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

Ошибки

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

admin_policy_enforced

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

disallowed_useragent

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

Андроид

Разработчики Android могут столкнуться с этим сообщением об ошибке при открытии запросов авторизации вandroid.webkit.WebView . Вместо этого разработчикам следует использовать библиотеки Android, такие как Google Sign-In для Android или AppAuth OpenID Foundation для Android .

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

iOS

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

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

org_internal

Идентификатор клиента OAuth в запросе является частью проекта, ограничивающего доступ к аккаунтам Google в определенной организации Google Cloud . Дополнительные сведения об этом параметре конфигурации см. в разделе « Тип пользователя» справочной статьи «Настройка экрана согласия OAuth».

redirect_uri_mismatch

redirect_uri , переданный в запросе авторизации, не соответствует авторизованному URI перенаправления для идентификатора клиента OAuth. Просмотрите разрешенные URI перенаправления в Google API Console Credentials page.

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

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

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

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

Шаг 5. Код авторизации Exchange для токенов обновления и доступа

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

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

В следующем фрагменте показан пример запроса:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http%3A//127.0.0.1%3A9004&
grant_type=authorization_code

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

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

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

В следующем фрагменте показан пример ответа:

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

Вызов API Google

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

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

Примеры HTTP-запроса

Вызов конечной точки drive.files (API Drive Files) с использованием HTTP-заголовка Authorization: Bearer может выглядеть следующим образом. Обратите внимание, что вам нужно указать свой собственный токен доступа:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

примеры curl

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Или, альтернативно, опция параметра строки запроса:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Обновление токена доступа

Токены доступа периодически истекают и становятся недействительными учетными данными для соответствующего запроса 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 Токен обновления, возвращенный в результате обмена кодом авторизации.

В следующем фрагменте показан пример запроса:

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

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Пока пользователь не отозвал доступ, предоставленный приложению, сервер токенов возвращает объект JSON, содержащий новый токен доступа. В следующем фрагменте показан пример ответа:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.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 вместе с кодом ошибки.

Дальнейшее чтение

IETF Best Current Practice OAuth 2.0 для нативных приложений устанавливает многие из задокументированных здесь передовых практик.