Связывание аккаунта 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, см. раздел Логотипы и товарные знаки .

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

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

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

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

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

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

  1. Откройте страницу экрана согласия OAuth консоли API Google.
  2. При появлении запроса выберите только что созданный проект.
  3. На странице «Экран согласия OAuth» заполните форму и нажмите кнопку «Сохранить».

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

    Логотип приложения: изображение на экране согласия, которое поможет пользователям узнать ваше приложение. Логотип отображается на экране согласия на привязку учетной записи и в настройках учетной записи.

    Электронная почта поддержки: чтобы пользователи могли связаться с вами и задать вопросы о своем согласии.

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

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

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

    Ссылка на политику конфиденциальности приложения: отображается на экране согласия на привязку учетной записи Google. Должен быть размещен на авторизованном домене.

    Ссылка на Условия использования приложения (необязательно): должна быть размещена в авторизованном домене.

    Рисунок 1 . Экран согласия на привязку учетной записи Google к вымышленному приложению, Tunery

  4. Проверьте «Статус проверки». Если ваше приложение требует проверки, нажмите кнопку «Отправить на проверку», чтобы отправить заявку на проверку. Подробную информацию см. в требованиях к проверке OAuth .

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

Параметры конечной точки авторизации
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

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

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

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

Например, если ваша конечная точка 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游乐场工具。

在工具中,执行以下步骤:

  1. 单击配置打开的OAuth 2.0配置窗口。
  2. OAuth流场中,选择客户端
  3. OAuth端点字段中,选择自定义
  4. 在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
  5. 步骤1部分,不要选择任何谷歌范围。相反,将此字段留空或键入对您的服务器有效的范围(如果不使用 OAuth 范围,则输入任意字符串)。当您完成后,单击授权的API。
  6. 步骤2步骤3段,完成OAuth 2.0流程和验证每个步骤按预期工作。

您可以通过验证您的实现谷歌帐户链接演示工具。

在工具中,执行以下步骤:

  1. 点击登录在与谷歌按钮。
  2. 选择您要关联的帐户。
  3. 输入服务标识。
  4. (可选)输入您将请求访问的一个或多个范围。
  5. 单击开始演示
  6. 出现提示时,确认您可以同意并拒绝链接请求。
  7. 确认您被重定向到您的平台。