Эта страница переведена с помощью Cloud Translation API.
Switch to English

Связывание аккаунта Google с помощью OAuth

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

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

В потоке кода авторизации вам понадобятся две конечные точки:

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

  • Конечная точка обмена токенами, которая отвечает за два типа обменов:

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

Выберите поток OAuth 2.0

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

Рекомендации по дизайну

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

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

Требования

  1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.

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

Мы рекомендуем вам сделать следующее:

  1. Показать Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

  2. Данные для обмена. Используйте ясный и лаконичный язык, чтобы сообщить пользователю, какие данные ему нужны Google и почему.

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

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

  5. Четкий процесс входа. Убедитесь, что у пользователей есть четкий способ входа в свою учетную запись Google, например поля для имени пользователя и пароля или Вход с помощью Google .

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

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

    • Если пользователю необходимо закрыть экран согласия для переключения учетных записей, отправьте в Google исправляемую ошибку, чтобы пользователь мог войти в желаемую учетную запись с привязкой OAuth и неявным потоком.
  8. Включите свой логотип. Отобразите логотип вашей компании на экране согласия. Используйте свои рекомендации по стилю, чтобы разместить свой логотип. Если вы хотите также отображать логотип Google, см. Логотипы и товарные знаки .

Настроить проект

Чтобы настроить проект для использования привязки учетной записи OAuth:

  1. Go to the Google API Console.
  2. Нажмите Создать проект .
  3. Введите имя или примите сгенерированное предложение.
  4. Подтвердите или отредактируйте оставшиеся поля.
  5. Нажмите Создать .

Для просмотра идентификатора вашего проекта:

  1. Go to the Google API Console.
  2. Найдите свой проект в таблице на целевой странице. Идентификатор проекта отображается в столбце идентификаторов .

Внедрите свой сервер OAuth

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

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

Сеанс потока кода авторизации OAuth 2.0, инициированный Google, имеет следующий поток:

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

Обработка запросов на авторизацию

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

Параметры конечной точки авторизации
client_id Идентификатор клиента Google, который вы зарегистрировали в Google.
redirect_uri URL-адрес, на который вы отправляете ответ на этот запрос.
state Бухгалтерская стоимость, которая возвращается в Google без изменений в URI перенаправления.
scope Необязательно: разделенный пробелами набор строк области видимости, в которых указываются данные, для которых Google запрашивает авторизацию.
response_type Тип значения, возвращаемого в ответе. Для потока кода авторизации OAuth 2.0 типом ответа всегда является code .
user_locale Настройка языка учетной записи Google в формате RFC5646 , используемая для локализации вашего контента на предпочтительный язык пользователя.

Например, если ваша конечная точка авторизации доступна по адресу https://myservice.example.com/auth , запрос может выглядеть следующим образом:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

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

  1. Убедитесь, что client_id соответствует идентификатору клиента Google, который вы зарегистрировали в Google, и что redirect_uri соответствует URL-адресу перенаправления, предоставленному Google для вашей службы. Эти проверки важны для предотвращения предоставления доступа непреднамеренным или неправильно настроенным клиентским приложениям. Если вы поддерживаете несколько потоков OAuth 2.0, также убедитесь, что response_type - это code .
  2. Проверьте, вошел ли пользователь в вашу службу. Если пользователь не вошел в систему, завершите процесс входа или регистрации в вашей службе.
  3. Сгенерируйте код авторизации, который Google будет использовать для доступа к вашему API. Код авторизации может быть любым строковым значением, но он должен однозначно представлять пользователя, клиента, для которого предназначен токен, и срок действия кода, и его нельзя угадывать. Обычно вы выдаете коды авторизации, срок действия которых истекает примерно через 10 минут.
  4. Убедитесь, что URL-адрес, указанный в параметре redirect_uri имеет следующий вид:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
      
  5. Перенаправьте браузер пользователя на URL-адрес, указанный в параметре redirect_uri . Включите только что сгенерированный код авторизации и исходное неизмененное значение состояния при перенаправлении, добавив параметры code и state . Ниже приведен пример полученного URL:
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Обработка запросов на обмен токенами

Конечная точка обмена токенами вашей службы отвечает за два типа обмена токенами:

  • Обмен кодами авторизации на токены доступа и токены обновления
  • Обменять токены обновления на токены доступа

Запросы на обмен токенами включают следующие параметры:

Параметры конечной точки обмена токенами
client_id Строка, определяющая источник запроса как Google. Эта строка должна быть зарегистрирована в вашей системе как уникальный идентификатор Google.
client_secret Секретная строка, которую вы зарегистрировали в Google для своей службы.
grant_type Тип обмениваемого токена. Это либо authorization_code либо refresh_token .
code Когда grant_type=authorization_code , этот параметр представляет собой код, полученный Google от конечной точки входа или обмена токенами.
redirect_uri Когда grant_type=authorization_code , этот параметр является URL-адресом, используемым в первоначальном запросе авторизации.
refresh_token Когда grant_type=refresh_token , этот параметр представляет собой токен обновления, полученный Google от вашей конечной точки обмена токенами.
Обмен кодами авторизации на токены доступа и токены обновления

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

Для этих запросов значение grant_type - authorization_code , а значение code - значение кода авторизации, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен кода авторизации на токен доступа и токен обновления:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Для обмена кодами авторизации для токена доступа и токена обновления ваша конечная точка обмена токенами отвечает на запросы POST , выполняя следующие шаги:

  1. Убедитесь, что client_id определяет источник запроса как авторизованный источник, и что client_secret соответствует ожидаемому значению.
  2. Убедитесь, что код авторизации действителен и не истек, и что идентификатор клиента, указанный в запросе, совпадает с идентификатором клиента, связанным с кодом авторизации.
  3. Убедитесь, что URL-адрес, указанный в параметре redirect_uri идентичен значению, используемому в первоначальном запросе авторизации.
  4. Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с {"error": "invalid_grant"} в качестве тела.
  5. В противном случае используйте идентификатор пользователя из кода авторизации для создания токена обновления и токена доступа. Эти токены могут иметь любое строковое значение, но они должны однозначно представлять пользователя и клиента, для которого предназначен токен, и их нельзя угадывать. Для токенов доступа также запишите время истечения срока действия токена, которое обычно составляет час после выдачи токена. Срок действия токенов обновления не истекает.
  6. Вернуть следующий объект JSON в теле ответа HTTPS:
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "refresh_token": "REFRESH_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }
    

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

Обменять токены обновления на токены доступа

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

Для этих запросов значение grant_type равно refresh_token , а значение refresh_token - это значение токена обновления, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен токена обновления на токен доступа:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

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

  1. Убедитесь, что client_id определяет источник запроса как Google, и что client_secret соответствует ожидаемому значению.
  2. Убедитесь, что токен обновления действителен и что идентификатор клиента, указанный в запросе, совпадает с идентификатором клиента, связанным с токеном обновления.
  3. Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с {"error": "invalid_grant"} в качестве тела.
  4. В противном случае используйте идентификатор пользователя из токена обновления для создания токена доступа. Эти токены могут иметь любое строковое значение, но они должны однозначно представлять пользователя и клиента, для которого предназначен токен, и их нельзя угадывать. Для токенов доступа также записывайте время истечения срока действия токена, обычно через час после выдачи токена.
  5. Верните следующий объект JSON в теле ответа HTTPS:
    {
    "token_type": "Bearer",
    "access_token": " ACCESS_TOKEN ",
    "expires_in": SECONDS_TO_EXPIRATION
    }

Проверка вашей реализации

Вы можете проверить свою реализацию с помощью инструмента OAuth 2.0 Playground .

В инструменте проделайте следующие шаги:

  1. Щелкните конфигурации чтобы открыть окно конфигурации OAuth 2.0.
  2. В поле потока OAuth выберите Client-side .
  3. В поле Конечные точки OAuth выберите Пользовательский .
  4. Укажите конечную точку OAuth 2.0 и идентификатор клиента, присвоенный Google, в соответствующих полях.
  5. В разделе Шаг 1 не выбирайте области Google. Вместо этого оставьте это поле пустым или введите область действия, действительную для вашего сервера (или произвольную строку, если вы не используете области действия OAuth). Когда вы закончите, нажмите « Авторизовать API» .
  6. В разделах Шаг 2 и Шаг 3 просмотрите поток OAuth 2.0 и убедитесь, что каждый шаг работает должным образом.

Вы можете проверить свою реализацию с помощью инструмента демонстрации связывания аккаунтов Google .

В инструменте проделайте следующие шаги:

  1. Нажмите кнопку Войти через Google .
  2. Выберите учетную запись, которую вы хотите связать.
  3. Введите идентификатор службы.
  4. При желании введите одну или несколько областей, для которых вы запрашиваете доступ.
  5. Щелкните « Начать демонстрацию» .
  6. При появлении запроса подтвердите, что вы можете согласиться, и отклоните запрос на установление связи.
  7. Подтвердите, что вы перенаправлены на свою платформу.