Google стремится продвигать расовое равенство для чернокожих сообществ. Смотри как.

Использование OAuth 2.0 для доступа к API Google

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

Для начала, получить OAuth клиента 2,0 учетные данные из Google API Console . Затем ваше клиентское приложение запрашивает токен доступа у сервера авторизации Google, извлекает токен из ответа и отправляет токен в API Google, к которому вы хотите получить доступ. Для интерактивной демонстрации с помощью OAuth 2.0 с помощью Google ( в том числе возможность использовать свои собственные учетные данные клиента), эксперимент с OAuth 2.0 Playground .

На этой странице представлен обзор сценариев авторизации OAuth 2.0, которые поддерживает Google, и приведены ссылки на более подробное содержание. Подробнее об использовании OAuth 2.0 для аутентификации см OpenID Connect .

Основные шаги

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

1. Получить OAuth 2.0 учетные данные из Google API Console.

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

2. Получите токен доступа с сервера авторизации Google.

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

Есть несколько способов сделать этот запрос, и они различаются в зависимости от типа создаваемого приложения. Например, приложение JavaScript может запросить токен доступа с помощью перенаправления браузера в Google, в то время как приложение, установленное на устройстве без браузера, использует запросы веб-службы.

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

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

Обычно рекомендуется запрашивать области постепенно, в то время, когда требуется доступ, а не заранее. Например, приложение, которое хочет поддерживать сохранение события в календаре, не должно запрашивать доступ к Календарю Google, пока пользователь не нажмет кнопку «Добавить в календарь»; см разрешения Инкрементального .

3. Изучите объемы доступа, предоставленные пользователем.

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

Область, включенная в ваш запрос, может не соответствовать области, включенной в ваш ответ, даже если пользователь предоставил все запрошенные области. См. Документацию по каждому API Google для получения информации об областях, необходимых для доступа. API может отображать несколько значений строки области видимости в единую область доступа, возвращая одну и ту же строку области видимости для всех значений, разрешенных в запросе. Пример: Google People API может возвращать сферу https://www.googleapis.com/auth/contacts , когда приложение просил пользователь авторизовать сферу https://www.google.com/m8/feeds/ ; метод Google People API people.updateContact требует предоставивший сферу https://www.googleapis.com/auth/contacts .

4. Отправьте токен доступа в API.

После того, как приложение получает маркер доступа, он посылает маркер к API Google в качестве заголовка запроса HTTP авторизации . Можно отправлять токены как параметры строки запроса URI, но мы не рекомендуем это делать, поскольку параметры URI могут попадать в файлы журнала, которые не являются полностью безопасными. Кроме того, рекомендуется избегать создания ненужных имен параметров URI. Обратите внимание, что поддержка строки запроса будет прекращена с 1 июня 2021 года.

Маркеры доступа действительны только для множества операций и ресурсов , описанных в scope маркеров запроса. Например, если для API Календаря Google выдается токен доступа, он не предоставляет доступ к API контактов Google. Однако вы можете отправить этот токен доступа в Google Calendar API несколько раз для аналогичных операций.

5. При необходимости обновите токен доступа.

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

Сценарии

Приложения веб-сервера

Конечная точка Google OAuth 2.0 поддерживает приложения веб-сервера, которые используют такие языки и платформы, как PHP, Java, Python, Ruby и ASP.NET.

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

Приложение должно хранить токен обновления для будущего использования и использовать токен доступа для доступа к Google API. По истечении срока действия токена доступа приложение использует токен обновления для получения нового.

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

Для получения дополнительной информации см Использование OAuth 2.0 для приложений веб - сервера .

Установленные приложения

Конечная точка Google OAuth 2.0 поддерживает приложения, установленные на таких устройствах, как компьютеры, мобильные устройства и планшеты. При создании идентификатора клиента через Google API Console , указать , что это установленное приложение, а затем выберите Android, Chrome приложение, IOS, универсальный Windows Platform (UWP) или приложение Desktop в качестве типа приложения.

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

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

Приложение должно хранить токен обновления для будущего использования и использовать токен доступа для доступа к Google API. По истечении срока действия токена доступа приложение использует токен обновления для получения нового.

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

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

Клиентские (JavaScript) приложения

Конечная точка Google OAuth 2.0 поддерживает приложения JavaScript, которые запускаются в браузере.

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

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

Ваше приложение JS отправляет запрос токена на сервер авторизации Google, получает токен, проверяет токен и использует токен для вызова конечной точки Google API.

Для получения дополнительной информации см Использование OAuth 2.0 для клиентских приложений .

Приложения на устройствах с ограниченным вводом

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

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

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

Между тем приложение опрашивает URL-адрес Google с заданным интервалом. После того, как пользователь подтвердит доступ, ответ сервера Google будет содержать токен доступа и токен обновления. Приложение должно хранить токен обновления для будущего использования и использовать токен доступа для доступа к Google API. По истечении срока действия токена доступа приложение использует токен обновления для получения нового.

Пользователь входит в систему на отдельном устройстве с браузером.

Для получения дополнительной информации см Использование OAuth 2.0 для устройств .

Сервисные аккаунты

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

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

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

Ваше серверное приложение использует JWT для запроса токена с сервера авторизации Google, а затем использует токен для вызова конечной точки Google API. Конечный пользователь не задействован.

Для получения дополнительной информации см документации обслуживания счетов .

Размер токена

Токены могут различаться по размеру до следующих ограничений:

  • Коды авторизации: 256 байт
  • Жетоны доступа: 2048 байт
  • Токены обновления: 512 байт

Доступ лексемы возвращаемого Google Облако API службы маркеров безопасности структурированы аналогично Google API OAuth токенов доступа 2,0 , но имеют различные ограничения размера маркеров. Для получения дополнительной информации см документации API .

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

Срок действия токена обновления

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

  • Пользователь аннулирован доступ вашего приложения .
  • Токен обновления не использовался в течение шести месяцев.
  • Пользователь изменил пароли, и токен обновления содержит области Gmail.
  • Учетная запись пользователя превысила максимальное количество предоставленных (действующих) токенов обновления.
  • Пользователь принадлежит к организации Google Cloud Platform, в которой действуют политики управления сеансами.

Проекту Google Cloud Platform с экраном согласия OAuth, настроенным для внешнего типа пользователя и статусом публикации «Тестирование», выдается токен обновления, срок действия которого истекает через 7 дней.

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

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

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

Работа с политиками управления сеансами для организаций Google Cloud Platform (GCP)

Администраторы GCP организаций могут потребовать частой повторной аутентификации пользователей при доступе GCP ресурсы, используя функцию управления сеансами Google Cloud . Эта политика влияет на доступ к Google Cloud Console, в Google Cloud SDK (также известный как CLI gcloud), и любого третья сторона приложению OAuth , которая требует объема Cloud Platform. Если пользователь имеет политику управления сеансом в месте , то по истечению длительности сеанса, ваше API вызовы выдаст ошибку подобно тому , что произошел бы , если обновление маркера был отменен - вызов завершится с типом ошибки invalid_token ; тип под-ошибки может использоваться, чтобы различать маркер отзыва и сбой из-за политики управления сеансом. Поскольку продолжительность сеанса может быть очень ограничена (от 1 часа до 24 часов), этот сценарий необходимо аккуратно обработать, перезапустив сеанс аутентификации.

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

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

Клиентские библиотеки

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