Упрощенная интеграция с OAuth и вход через Google.

Обзор

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

Для привязки учетной записи к OAuth и входа через Google выполните следующие общие шаги:

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

Рисунок 1. Привязка учетной записи на телефоне пользователя с помощью упрощенной привязки.

Упрощенная интеграция: OAuth + вход через Google Flow

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

Пользователь Приложение Google / Сервер Ваш токен Конечная точка обмена Ваш API 1. Пользователь инициирует создание ссылки. 2. Запросить вход через Google. 3. Войдите через Google. 4. Проверка намерения (утверждение JWT) 5. account_found: true/false Если учетная запись найдена: 6. Получить намерение Если нет учетной записи: 6. Создайте намерение 7. access_token, refresh_token 8. Хранение пользовательских токенов 9. Доступ к пользовательским ресурсам
Рисунок 2. Последовательность событий в оптимизированном процессе связывания.

Роли и обязанности

В приведенной ниже таблице определены роли и обязанности участников процесса упрощенного связывания.

Актер / Компонент GAL Role Обязанности
Приложение/сервер Google Клиент OAuth Получает согласие пользователя на вход через Google, передает подтверждения личности (JWT) на ваш сервер и надежно хранит полученные токены.
Ваша конечная точка обмена токенов Поставщик идентификационных данных / Сервер авторизации Проверяет подлинность учетных записей, проверяет наличие существующих учетных записей, обрабатывает намерения привязки учетных записей ( check , get , create ) и выдает токены на основе запрошенных намерений.
Ваш API сервиса Сервер ресурсов Предоставляет доступ к пользовательским данным при предъявлении действительного токена доступа.

Требования к упрощенной системе ссылок

  • Реализуйте базовый процесс привязки OAuth . Ваш сервис должен поддерживать конечные точки авторизации и обмена токенами , соответствующие стандарту OAuth 2.0.
  • Ваша конечная точка обмена токенами должна поддерживать утверждения JSON Web Token (JWT) и реализовывать намерения check , create и get .

Логика принятия решений для упрощения процесса связывания

Следующая логика определяет, как вызываются интенты в процессе упрощенной интеграции ссылок:

  1. Есть ли у пользователя учетная запись в вашей системе аутентификации? (Пользователь принимает решение, выбирая «ДА» или «НЕТ»)
    1. ДА: Использует ли пользователь адрес электронной почты, связанный с его учетной записью Google, для входа на вашу платформу? (Пользователь принимает решение, выбирая ДА или НЕТ)
      1. ДА: Есть ли у пользователя соответствующая учетная запись в вашей системе аутентификации? (для подтверждения вызывается check intent )
        1. ДА: если запрос get intent intent успешно завершается, то вызывается метод getIntent, и учетная запись связывается.
        2. НЕТ: Создать новую учетную запись? (Пользователь принимает решение, выбирая ДА или НЕТ)
          1. ДА: если функция создания create intent успешно завершается, вызывается метод createint, и учетная запись связывается.
          2. НЕТ: Запускается процесс авторизации OAuth, пользователь перенаправляется в свой браузер, и ему предоставляется возможность связаться с помощью другого адреса электронной почты.
      2. NO : The OAuth linking flow is triggered, the user is directed to their browser, and the user is given the option to link with a different email.
    2. НЕТ: Есть ли у пользователя соответствующая учетная запись в вашей системе аутентификации? (для подтверждения вызывается check intent )
      1. ДА: если запрос get intent intent успешно завершается, то вызывается метод getIntent, и учетная запись связывается.
      2. НЕТ: если функция создания намерения успешно завершается, вызывается метод create intent , и учетная запись связывается.

Рецепт реализации

Для поддержки упрощенной привязки (Streamlined Linking) ваша конечная точка обмена токенов должна реализовывать интенты check , get и create токенов.

Выполните следующие шаги для обработки различных намерений:

Check for an existing user account (check intent)

Google calls your token exchange endpoint to verify if the Google user exists in your system. For parameter details, see Streamlined Linking Intents.

Implementation Recipe

To handle the check intent, perform the following actions:

  1. Validate the request:

    • Verify client_id, client_secret, and grant_type (must be urn:ietf:params:oauth:grant-type:jwt-bearer).
    • Validate the assertion (JWT) using the criteria in JWT Validation.
  2. Lookup user:

    • Check if the Google Account ID (sub) or email address in the JWT matches a user in your database.
  3. Respond:

    • If found: Return HTTP 200 OK with {"account_found": "true"}.
    • If not found: Return HTTP 404 Not Found with {"account_found": "false"}.

Handle automatic linking (get intent)

If the account exists, Google calls your endpoint with intent=get to retrieve tokens. For parameter details, see Streamlined Linking Intents.

Implementation Recipe

To handle the get intent, perform the following actions:

  1. Validate the request:

    • Verify client_id, client_secret, and grant_type.
    • Validate the assertion (JWT).
  2. Lookup user:

    • Verify the user exists using the sub or email claim.
  3. Respond:

    • If successful: Generate and return access_token, refresh_token, and expires_in in a JSON response (HTTP 200 OK).
    • If linking fails: Return HTTP 401 Unauthorized with {"error": "linking_error"} and an optional login_hint to fall back to standard OAuth linking.

Handle account creation using Sign in with Google (create intent)

If no account exists, Google calls your endpoint with intent=create to create a new user. For parameter details, see Streamlined Linking Intents.

Implementation Recipe

To handle the create intent, perform the following actions:

  1. Validate the request:

    • Verify client_id, client_secret, and grant_type.
    • Validate the assertion (JWT).
  2. Verify user does not exist:

    • Check if the sub or email is already in your database.
    • If the user does exist: Return HTTP 401 Unauthorized with {"error": "linking_error", "login_hint": "USER_EMAIL"} to force fallback to OAuth linking.
  3. Create account:

    • Use the sub, email, name, and picture claims from the JWT to create a new user record.
  4. Respond:

    • Generate and return tokens in a JSON response (HTTP 200 OK).

Получите свой идентификатор клиента Google API.

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

  1. Перейдите на страницу «Клиенты» .
  2. Создайте или выберите проект Google API.

    Если для вашего проекта отсутствует идентификатор клиента (Client ID) для типа веб-приложения, нажмите «Создать клиент» (Create Client) , чтобы его создать. Обязательно укажите домен вашего сайта в поле «Разрешенные источники JavaScript» . При локальном тестировании или разработке необходимо добавить в поле «Разрешенные источники JavaScript» как http://localhost так и http://localhost:<port_number> .

Проверьте правильность вашей реализации.

You can validate your implementation by using the OAuth 2.0 Playground tool.

In the tool, do the following steps:

  1. Click Configuration to open the OAuth 2.0 Configuration window.
  2. In the OAuth flow field, select Client-side.
  3. In the OAuth Endpoints field, select Custom.
  4. Specify your OAuth 2.0 endpoint and the client ID you assigned to Google in the corresponding fields.
  5. In the Step 1 section, don't select any Google scopes. Instead, leave this field blank or type a scope valid for your server (or an arbitrary string if you don't use OAuth scopes). When you're done, click Authorize APIs.
  6. In the Step 2 and Step 3 sections, go through the OAuth 2.0 flow and verify that each step works as intended.

You can validate your implementation by using the Google Account Linking Demo tool.

In the tool, do the following steps:

  1. Click the Sign in with Google button.
  2. Choose the account you'd like to link.
  3. Enter the service ID.
  4. Optionally enter one or more scopes that you will request access for.
  5. Click Start Demo.
  6. When prompted, confirm that you may consent and deny the linking request.
  7. Confirm that you are redirected to your platform.