Связывание аккаунта 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,你的服务使可用的。第一个端点是授权端点,它负责查找或获得用户对数据访问的同意。授权端点向尚未登录的用户显示登录 UI,并记录对请求访问的同意。第二个端点是令牌交换端点,用于获取加密字符串,称为令牌,授权用户访问您的服务。

当 Google 应用程序需要调用您的服务的某个 API 时,Google 会结合使用这些端点来获得您的用户的许可,以代表他们调用这些 API。

Google发起的一次OAuth 2.0授权码流会话流程如下:

  1. Google 在用户的浏览器中打开您的授权端点。如果流程在 Action 的纯语音设备上开始,Google 会将执行转移到手机。
  2. 用户登录(如果尚未登录)并授予 Google 使用您的 API 访问其数据的权限(如果他们尚未授予权限)。
  3. 您的服务创建一个授权码,并返回给谷歌。为此,请将用户的浏览器重定向回 Google,并将授权代码附加到请求中。
  4. 谷歌发送授权代码,您的令牌交换终结,从而验证代码的真实性,并返回一个访问令牌刷新令牌。访问令牌是一个短期令牌,您的服务接受它作为访问 API 的凭据。刷新令牌是一个长期存在的令牌,Google 可以存储它并在它们到期时使用它来获取新的访问令牌。
  5. 用户完成帐户关联流程后,从 Google 发送的每个后续请求都包含一个访问令牌。

处理授权请求

当您需要使用 OAuth 2.0 授权代码流执行帐户关联时,Google 会将用户发送到您的授权端点,并发送一个包含以下参数的请求:

授权端点参数
client_id您分配给 Google 的客户 ID。
redirect_uri您向其发送对此请求的响应的 URL。
state传递回 Google 的簿记值在重定向 URI 中保持不变。
scope可选:以空格分隔的集合,其指定谷歌正在请求授权的数据范围的字符串。
response_type要在响应中返回的值的类型。对于的OAuth 2.0授权码流,响应类型总是code
user_locale在谷歌帐户语言设置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您分配给谷歌的客户ID匹配,并且该redirect_uri由谷歌为您服务提供的重定向URL匹配。这些检查对于防止授予对意外或配置错误的客户端应用程序的访问权限非常重要。如果你支持多种OAuth 2.0流程的,也确认response_typecode
  2. 检查用户是否已登录您的服务。如果用户未登录,请完成服务的登录或注册流程。
  3. 生成供 Google 用于访问您的 API 的授权代码。授权码可以是任何字符串值,但必须唯一代表用户、token所针对的客户端、授权码的过期时间,并且不能被猜到。您通常会发出大约 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参数。当你通过附加重定向包括刚刚生成授权码和原始未修正的状态值codestate参数。以下是所得的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_coderefresh_token
codegrant_type=authorization_code ,这个参数是从您登录或令牌交换终结收到谷歌的代码。
redirect_urigrant_type=authorization_code ,该参数是在初始授权请求中使用的URL。
refresh_tokengrant_type=refresh_token ,这个参数是令牌从令牌交换终结收到谷歌的刷新。
交换访问令牌和刷新令牌的授权代码

在用户登录并且您的授权端点向 Google 返回一个短期授权代码后,Google 会向您的令牌交换端点发送请求,以交换访问令牌和刷新令牌的授权代码。

对于这些请求,价值grant_typeauthorization_code ,和值code是您先前授予给谷歌授权码的值。以下是为访问令牌和刷新令牌交换授权代码的请求示例:

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

要为访问Exchange授权码令牌和刷新令牌,您的令牌交换终结响应POST通过执行以下步骤要求:

  1. 验证该client_id识别为授权原点,并且所述请求源client_secret预期值相匹配。
  2. 验证授权码是否有效且未过期,以及请求中指定的客户端 ID 是否与与授权码关联的客户端 ID 匹配。
  3. 确认URL中指定由redirect_uri参数是相同的初始授权请求中使用的值。
  4. 如果您无法验证所有的上述标准,则返回一个HTTP 400错误的请求错误与{"error": "invalid_grant"}作为身体。
  5. 否则,使用授权代码中的用户 ID 生成刷新令牌和访问令牌。这些令牌可以是任何字符串值,但它们必须唯一地代表令牌所针对的用户和客户端,并且不能被猜测。对于访问令牌,还要记录令牌的到期时间,通常是您发出令牌后的一个小时。刷新令牌不会过期。
  6. 返回以下JSON对象在HTTPS响应的主体:
    {
    "token_type": "Bearer",
    "access_token": "ACCESS_TOKEN",
    "refresh_token": "REFRESH_TOKEN",
    "expires_in": SECONDS_TO_EXPIRATION
    }
    

Google 为用户存储访问令牌和刷新令牌,并记录访问令牌的到期时间。当访问令牌过期时,Google 使用刷新令牌从您的令牌交换端点获取新的访问令牌。

交换刷新令牌以获取访问令牌

当访问令牌过期时,Google 会向您的令牌交换端点发送请求,以将刷新令牌交换为新的访问令牌。

对于这些请求,价值grant_typerefresh_token ,和值refresh_token是令牌先前授予谷歌刷新的值。以下是将刷新令牌交换为访问令牌的请求示例:

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标识请求起源谷歌,那client_secret预期值相符。
  2. 验证刷新令牌是否有效,以及请求中指定的客户端 ID 是否与与刷新令牌关联的客户端 ID 匹配。
  3. 如果您无法验证所有的上述标准,则返回一个HTTP 400错误的请求错误与{"error": "invalid_grant"}作为身体。
  4. 否则,使用刷新令牌中的用户 ID 生成访问令牌。这些令牌可以是任何字符串值,但它们必须唯一地代表令牌所针对的用户和客户端,并且它们不能被猜测。对于访问令牌,还要记录令牌的到期时间,通常是在您发出令牌后的一个小时。
  5. 在 HTTPS 响应的正文中返回以下 JSON 对象:
    {
    "token_type": "Bearer",
    "access_token": " ACCESS_TOKEN ",
    "expires_in": SECONDS_TO_EXPIRATION
    }
Обработка запросов информации пользователя

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

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

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

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

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

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

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

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

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

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

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