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

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

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

Create the project

To create your project to use account linking:

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

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

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

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

1. Open the OAuth consent screen page of the Google APIs console.
2. If prompted, select the project you just created.

3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

   Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

   Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

   Support email: For users to contact you with questions about their consent.

   Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

   Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

   Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

   Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

   Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

   

   Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

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

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

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

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

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

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

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

Например, если ваша конечная точка авторизации доступна по адресу 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

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

1. Проверьте значения 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
     

2. Проверьте, вошел ли пользователь в ваш сервис. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей службе.

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

4. Отправьте 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

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

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

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

• Вход в связанную учетную запись с помощью Google One Tap.
• Простая подписка на AndroidTV.

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

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

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

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

1. Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
2. Если токен доступа недействителен, верните ошибку HTTP 401 Unauthorized с использованием заголовка ответа WWW-Authenticate . Ниже приведен пример ответа об ошибке с информацией о пользователе:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

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

3. Если токен доступа действителен, верните ответ 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 пользователя.

   ответ конечной точки с информацией о пользователе
   sub	Уникальный идентификатор, идентифицирующий пользователя в вашей системе.
   email	Адрес электронной почты пользователя.
   given_name	Необязательно: Имя пользователя.
   family_name	Необязательно: фамилия пользователя.
   name	Необязательно: Полное имя пользователя.
   picture	Необязательно: изображение профиля пользователя.

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

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

В инструменте выполните следующие действия:

1. Нажмите settings конфигурации» , чтобы открыть окно «Конфигурация OAuth 2.0».
2. В поле «Поток OAuth» выберите «Клиентская сторона» .
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. Подтвердите, что вы перенаправлены на вашу платформу.

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

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

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

Рекомендации по проектированию

В этом разделе описаны требования и рекомендации к дизайну пользовательского экрана, который вы размещаете для связывания потоков OAuth. После вызова приложения Google ваша платформа отображает пользователю страницу входа в систему и экран согласия привязки учетной записи. Пользователь перенаправляется обратно в приложение 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, см. раздел Логотипы и товарные знаки .

Create the project

To create your project to use account linking:

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

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

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

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

1. Open the OAuth consent screen page of the Google APIs console.
2. If prompted, select the project you just created.

3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

   Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

   Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

   Support email: For users to contact you with questions about their consent.

   Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

   Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

   Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

   Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

   Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

   

   Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

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

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

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

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

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

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

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

Например, если ваша конечная точка авторизации доступна по адресу 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

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

1. Проверьте значения 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
     

2. Проверьте, вошел ли пользователь в ваш сервис. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей службе.

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

4. Отправьте 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

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

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

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

• Вход в связанную учетную запись с помощью Google One Tap.
• Простая подписка на AndroidTV.

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

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

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

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

1. Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
2. Если токен доступа недействителен, верните ошибку HTTP 401 Unauthorized с использованием заголовка ответа WWW-Authenticate . Ниже приведен пример ответа об ошибке с информацией о пользователе:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

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

3. Если токен доступа действителен, верните ответ 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 пользователя.

   ответ конечной точки с информацией о пользователе
   sub	Уникальный идентификатор, идентифицирующий пользователя в вашей системе.
   email	Адрес электронной почты пользователя.
   given_name	Необязательно: Имя пользователя.
   family_name	Необязательно: фамилия пользователя.
   name	Необязательно: Полное имя пользователя.
   picture	Необязательно: изображение профиля пользователя.

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

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

В инструменте выполните следующие действия:

1. Нажмите settings конфигурации» , чтобы открыть окно «Конфигурация OAuth 2.0».
2. В поле «Поток OAuth» выберите «Клиентская сторона» .
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. Подтвердите, что вы перенаправлены на вашу платформу.