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

Связывание аккаунта Google с OAuth

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

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

В потоке кода авторизации вам нужны две конечные точки:

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

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

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

потока

Требования

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

Создать проект

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

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

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

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

Настройте экран согласия OAuth

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

Откройте страницу экрана согласия OAuth в консоли Google API.
При появлении запроса выберите только что созданный проект.
На странице «Экран согласия OAuth» заполните форму и нажмите кнопку «Сохранить».
Имя приложения: имя приложения, запрашивающего согласие. Имя должно точно отражать ваше приложение и согласовываться с именем приложения, которое пользователи видят в другом месте. Имя приложения будет отображаться на экране согласия на привязку учетной записи.
Логотип приложения: изображение на экране согласия, которое поможет пользователям узнать ваше приложение. Логотип отображается на экране согласия на привязку учетной записи и в настройках учетной записи .
Электронная почта службы поддержки: чтобы пользователи могли обращаться к вам с вопросами о своем согласии.
Области для Google API: Области позволяют вашему приложению получать доступ к личным данным Google вашего пользователя. Для варианта использования привязки учетной записи Google достаточно области по умолчанию (электронная почта, профиль, openid), вам не нужно добавлять какие-либо конфиденциальные области. Как правило, рекомендуется запрашивать области постепенно, в то время, когда требуется доступ, а не заранее. Узнать больше .
Авторизованные домены. Чтобы защитить вас и ваших пользователей, Google разрешает использовать авторизованные домены только приложениям, которые проходят аутентификацию с использованием OAuth. Ссылки на ваши приложения должны размещаться на авторизованных доменах. Узнать больше .
Ссылка на домашнюю страницу приложения : домашняя страница вашего приложения. Должен размещаться на авторизованном домене.
Ссылка на политику конфиденциальности приложений: отображается на экране согласия на привязку аккаунта Google. Должен размещаться на авторизованном домене.
Ссылка на условия использования приложения (необязательно): должна размещаться на авторизованном домене.
Рисунок 1 . Экран согласия на привязку учетной записи Google к фиктивному приложению, Tunery
Проверьте «Статус проверки», если ваше приложение нуждается в проверке, затем нажмите кнопку «Отправить на проверку», чтобы отправить заявку на проверку. Дополнительные сведения см. в требованиях к проверке OAuth .

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

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

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

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

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

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

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

Параметры конечной точки авторизации
`client_id`	Идентификатор клиента, который вы присвоили Google.
`redirect_uri`	URL-адрес, на который вы отправляете ответ на этот запрос.
`state`	Бухгалтерская стоимость, которая возвращается в Google без изменений в URI перенаправления.
`response_type`	Тип значения, возвращаемого в ответе. Для неявного потока OAuth 2.0, тип ответа всегда `token` .
`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&response_type=token&user_locale=LOCALE

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

Проверьте client_id и redirect_uri значения для предотвращения предоставления доступа к непредвиденным или некорректной настройки приложений клиента:
- Убедитесь , что client_id соответствует идентификатор клиента, назначенный для Google.
- Убедитесь , что URL - адрес задается redirect_uri параметром имеет следующий вид:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
```
Проверьте, вошел ли пользователь в вашу службу. Если пользователь не вошел в систему, завершите процесс входа или регистрации в вашей службе.
Создайте токен доступа, который Google будет использовать для доступа к вашему API. Токеном доступа может быть любое строковое значение, но он должен однозначно представлять пользователя и клиента, для которого предназначен токен, и его нельзя угадывать.
Отправить ответ HTTP , который перенаправляет браузер пользователя на URL , указанный redirect_uri параметра. Включите во фрагмент URL все следующие параметры:
- access_token : Доступ лексемы вы только что генерируется
- token_type : Строка bearer
- state : Неизмененное значение состояния из исходного запроса
Ниже приведен пример результирующего URL:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
```

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

Обработка запросов информации пользователя

UserInfo конечной точкой является OAuth 2,0 защищенный ресурс, возвратные претензии по поводу связанного пользователя. Внедрение и размещение конечной точки userinfo необязательно, за исключением следующих случаев использования:

Linked входа в аккаунт с Google One Tap.
Frictionless подписка на AndroidTV.

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

заголовки запроса конечной точки userinfo
`Authorization header`	Маркер доступа типа Bearer.

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

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

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

Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
Если маркер доступа неверен, возвращает Несанкционированное ошибку HTTP 401 с помощью WWW-Authenticate заголовок ответа. Ниже приведен пример ответа ошибки UserInfo:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
Если 401 Несанкционированные, или любой другой неудачный ответ возвращается ошибка во время процесса , связывающего, ошибка будет неустранимой, извлеченный маркер будет отброшен , и пользователь будет иметь чтобы снова запустить процесс связывания.

Если маркер доступа действителен, возврат и HTTP 200 ответ со следующим объектом JSON в теле ответа HTTPS:

{
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}

Если ваша USERINFO конечная точка возвращает ответ успех HTTP 200, извлеченный маркер и претензии зарегистрированы на Google пользователя учетная запись.

ответ конечной точки userinfo
`sub`	Уникальный идентификатор, который идентифицирует пользователя в вашей системе.
`email`	Электронный адрес пользователя.
`given_name`	Дополнительно: Имя пользователя.
`family_name`	Дополнительно: Фамилия пользователя.
`name`	Дополнительно: Полное имя пользователя.
`picture`	Дополнительно: Рисунок профиля пользователя.

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

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

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

Нажмите Конфигурация , чтобы открыть окно настройки OAuth 2.0.
В поле потока OAuth, выберите на стороне клиента.
В поле OAuth Endpoints, выберите Custom.
Укажите конечную точку OAuth 2.0 и идентификатор клиента, назначенный Google, в соответствующих полях.
В разделе Шаг 1, не выбирайте области Google. Вместо этого оставьте это поле пустым или введите область действия, действительную для вашего сервера (или произвольную строку, если вы не используете области действия OAuth). Когда вы закончите, нажмите Авторизовать API.
В секциях Шаг 2 и Шаг 3, пройти через поток OAuth 2.0 и убедитесь , что каждый шаг работает как задумано.

Вы можете проверить свою реализацию с помощью учетной записи Google Linking Демо инструмент.