Учетные записи связаны с использованием неявного отраслевого стандарта OAuth 2.0 и потоков кода авторизации . Ваш сервис должен поддерживать авторизацию и конечные точки обмена токенами , совместимые с OAuth 2.0.
在隐式流程中,Google 会在用户的浏览器中打开您的授权端点。成功登录后,您将向 Google 返回一个长期访问令牌。现在,此访问令牌会包含在 Google 发送的每个请求中。
在授权代码流程中,您需要两个端点:
授权端点,用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期授权代码,以记录用户对所请求访问权限的同意情况。
令牌交换端点,负责两种类型的交换:
- 使用授权代码换取长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时,就会发生此交换。
- 将长期有效的刷新令牌换成短期有效的访问令牌。当 Google 需要新的访问令牌(因为现有访问令牌已过期)时,就会发生这种交换。
选择 OAuth 2.0 流程
虽然隐式流程更易于实现,但 Google 建议通过隐式流程签发的访问令牌永不过期。这是因为,在隐式流程中,令牌过期后,系统会强制用户重新关联其账号。如果您出于安全考虑需要令牌过期,我们强烈建议您改用授权码流程。
设计准则
本部分介绍了您为 OAuth 关联流程托管的用户屏幕的设计要求和建议。在 Google 应用调用该 API 后,您的平台会向用户显示登录 Google 页面和账号关联意见征求界面。同意关联账号后,系统会将用户重定向回 Google 的应用。

要求
- 您必须说明用户的账号将与 Google 相关联,而非 Google Home 或 Google 助理等特定 Google 产品相关联。
建议
建议您执行以下操作:
显示 Google 的隐私权政策。在同意屏幕上添加指向 Google 隐私权政策的链接。
要共享的数据。使用清晰简洁的语言告知用户 Google 需要哪些用户数据以及原因。
添加醒目的号召性用语。在用户同意页面上提供明确的号召性用语,例如“同意并关联”。这是因为用户需要了解他们需要与 Google 分享哪些数据才能关联账号。
可以取消。为用户提供返回或取消链接的途径,如果用户选择不进行关联。
明确的登录流程。确保用户有明确的 Google 账号登录方法,例如用户名和密码字段或使用 Google 账号登录。
能够解除关联。提供一种可让用户解除关联的机制,例如指向您平台上账号设置的网址。或者,您也可以添加指向 Google 账号的链接,以便用户管理其关联的账号。
能够更改用户账号。建议用户切换账号的方法。如果用户通常拥有多个账号,这种做法尤为有益。
- 如果用户必须关闭意见征求界面才能切换账号,请向 Google 发送可恢复的错误,以便用户可以使用 OAuth 关联和隐式流程登录所需的账号。
添加您的徽标。在意见征求页面上显示您的公司徽标。 按照您的样式准则放置徽标。如果您还想显示 Google 的徽标,请参阅徽标和商标。

Create the project
To create your project to use account linking:
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.
- Open the OAuth consent screen page of the Google APIs console.
- If prompted, select the project you just created.
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
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, имеет следующий процесс:
- Google открывает вашу конечную точку авторизации в браузере пользователя. Если поток для действия начался на голосовом устройстве, Google передает выполнение на телефон.
- Пользователь входит в систему, если он еще не вошел в систему, и предоставляет Google разрешение на доступ к своим данным с помощью вашего API, если он еще не предоставил разрешение.
- Ваш сервис создает код авторизации и возвращает его в Google. Для этого перенаправьте браузер пользователя обратно в Google, указав код авторизации, прикрепленный к запросу.
- Google отправляет код авторизации в конечную точку обмена токенами, которая проверяет подлинность кода и возвращает токен доступа и токен обновления . Токен доступа — это недолговечный токен, который ваша служба принимает в качестве учетных данных для доступа к API. Токен обновления — это долгосрочный токен, который Google может хранить и использовать для получения новых токенов доступа по истечении срока их действия.
- После того как пользователь завершил процесс привязки учетной записи, каждый последующий запрос, отправленный от Google, содержит токен доступа.
Обработка запросов на авторизацию
Когда вам необходимо выполнить привязку учетной записи с использованием потока кода авторизации OAuth 2.0, Google отправляет пользователя в вашу конечную точку авторизации с запросом, который включает следующие параметры:
Параметры конечной точки авторизации | |
---|---|
client_id | Идентификатор клиента, который вы назначили Google. |
redirect_uri | URL-адрес, на который вы отправляете ответ на этот запрос. |
state | Бухгалтерское значение, которое передается обратно в Google без изменений в URI перенаправления. |
scope | Необязательно: набор строк области действия, разделенных пробелами, которые определяют данные, для которых Google запрашивает авторизацию. |
response_type | Тип значения, возвращаемого в ответе. Для потока кода авторизации OAuth 2.0 тип ответа всегда — code . |
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 &scope=REQUESTED_SCOPES &response_type=code&user_locale=LOCALE
Чтобы конечная точка авторизации могла обрабатывать запросы на вход, выполните следующие действия:
- Убедитесь, что
client_id
соответствует идентификатору клиента, который вы назначили Google, и чтоredirect_uri
соответствует URL-адресу перенаправления, предоставленному Google для вашей службы. Эти проверки важны для предотвращения предоставления доступа непреднамеренным или неправильно настроенным клиентским приложениям. Если вы поддерживаете несколько потоков OAuth 2.0, также убедитесь, чтоresponse_type
равенcode
. - Проверьте, вошел ли пользователь в ваш сервис. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей службе.
- Создайте код авторизации, который Google будет использовать для доступа к вашему API. Код авторизации может быть любым строковым значением, но он должен однозначно представлять пользователя, клиента, для которого предназначен токен, а также время истечения срока действия кода, и его нельзя угадывать. Обычно вы выдаете коды авторизации, срок действия которых истекает примерно через 10 минут.
- Убедитесь, что URL-адрес, указанный параметром
redirect_uri
, имеет следующую форму:https://oauth-redirect.googleusercontent.com/r/
YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID - Перенаправьте браузер пользователя на URL-адрес, указанный параметром
redirect_uri
. Включите только что сгенерированный код авторизации и исходное неизмененное значение состояния при перенаправлении, добавив параметрыcode
иstate
. Ниже приведен пример результирующего 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_code , либо refresh_token . |
code | grant_type=authorization_code , этот параметр представляет собой код, который Google получил либо от вашей конечной точки входа в систему, либо от конечной точки обмена токенами. |
redirect_uri | grant_type=authorization_code , этот параметр представляет собой URL-адрес, используемый в первоначальном запросе авторизации. |
refresh_token | grant_type=refresh_token , этот параметр представляет собой токен обновления, который Google получил от вашей конечной точки обмена токенами. |
Обмен кодами авторизации для токенов доступа и токенов обновления.
После того как пользователь входит в систему и ваша конечная точка авторизации возвращает в Google кратковременный код авторизации, Google отправляет запрос на вашу конечную точку обмена токенами, чтобы обменять код авторизации на токен доступа и токен обновления.
Для этих запросов значение grant_type
— authorization_code
, а значение code
— это значение кода авторизации, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен кода авторизации на токен доступа и токен обновления:
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
Чтобы обменять коды авторизации для токена доступа и токена обновления, ваша конечная точка обмена токенами отвечает на запросы POST
, выполняя следующие шаги:
- Убедитесь, что
client_id
идентифицирует источник запроса как авторизованный источник и чтоclient_secret
соответствует ожидаемому значению. - Убедитесь, что код авторизации действителен, срок его действия не истек, а идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с кодом авторизации.
- Убедитесь, что URL-адрес, указанный в параметре
redirect_uri
, идентичен значению, используемому в первоначальном запросе авторизации. - Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с
{"error": "invalid_grant"}
в качестве тела. - В противном случае используйте идентификатор пользователя из кода авторизации для создания токена обновления и токена доступа. Эти токены могут быть любыми строковыми значениями, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадывать. Для токенов доступа также запишите срок действия токена, который обычно составляет час после выдачи токена. Токены обновления не имеют срока действия.
- Верните следующий объект JSON в текст ответа HTTPS:
{ "token_type": "Bearer", "access_token": "
ACCESS_TOKEN ", "refresh_token": "REFRESH_TOKEN ", "expires_in":SECONDS_TO_EXPIRATION }
Google хранит токен доступа и токен обновления для пользователя и записывает срок действия токена доступа. По истечении срока действия токена доступа Google использует токен обновления, чтобы получить новый токен доступа из вашей конечной точки обмена токенами.
Обмен токенов обновления на токены доступа
Когда срок действия токена доступа истекает, Google отправляет запрос на вашу конечную точку обмена токенами, чтобы обменять токен обновления на новый токен доступа.
Для этих запросов grant_type
— refresh_token
, а refresh_token
— это значение токена обновления, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен токена обновления на токен доступа:
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
, выполняя следующие шаги:
- Убедитесь, что
client_id
идентифицирует источник запроса как Google и чтоclient_secret
соответствует ожидаемому значению. - Убедитесь, что токен обновления действителен и что идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с токеном обновления.
- Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с
{"error": "invalid_grant"}
в качестве тела. - В противном случае используйте идентификатор пользователя из токена обновления для создания токена доступа. Эти токены могут быть любыми строковыми значениями, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадывать. Для токенов доступа также запишите срок действия токена, обычно через час после выдачи токена.
- Верните следующий объект JSON в текст ответа HTTPS:
{
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN ",
"expires_in":SECONDS_TO_EXPIRATION
}
Обработка запросов информации о пользователях
Конечная точка userinfo — это ресурс, защищенный OAuth 2.0, который возвращает утверждения о связанном пользователе. Реализация и размещение конечной точки userinfo не является обязательной, за исключением следующих случаев использования:
- Вход в связанную учетную запись с помощью Google One Tap.
- Простая подписка на AndroidTV.
После того как токен доступа был успешно получен из конечной точки вашего токена, 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 могла обрабатывать запросы, выполните следующие действия:
- Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
- Если токен доступа недействителен, верните ошибку HTTP 401 Unauthorized с использованием заголовка ответа
WWW-Authenticate
. Ниже приведен пример ответа об ошибке с информацией о пользователе: Если в процессе связывания возвращается ошибка 401 Unauthorized или любой другой неудачный ответ об ошибке, ошибка будет невосстановимой, полученный токен будет отброшен, и пользователю придется снова инициировать процесс связывания.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Если токен доступа действителен, верните ответ HTTP 200 со следующим объектом JSON в теле ответа HTTPS:
Если ваша конечная точка userinfo возвращает успешный ответ HTTP 200, полученный токен и утверждения регистрируются в учетной записи Google пользователя.{ "sub": "
USER_UUID ", "email": "EMAIL_ADDRESS ", "given_name": "FIRST_NAME ", "family_name": "LAST_NAME ", "name": "FULL_NAME ", "picture": "PROFILE_PICTURE ", }ответ конечной точки с информацией о пользователе sub
Уникальный идентификатор, идентифицирующий пользователя в вашей системе. email
Адрес электронной почты пользователя. given_name
Необязательно: Имя пользователя. family_name
Необязательно: фамилия пользователя. name
Необязательно: Полное имя пользователя. picture
Необязательно: изображение профиля пользователя.
Проверка вашей реализации
您可以使用 OAuth 2.0 Playground 工具验证您的实现。
在该工具中,执行以下步骤:
- 点击配置 以打开 OAuth 2.0 配置窗口。
- 在 OAuth flow 字段中,选择 Client-side(客户端)。
- 在 OAuth 端点字段中,选择自定义。
- 在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
- 在第 1 步部分,不要选择任何 Google 范围。请将此字段留空或输入对服务器有效的范围(如果您不使用 OAuth 范围,则可以输入任意字符串)。完成后,点击授权 API。
- 在 Step 2 和 Step 3 部分中,完成 OAuth 2.0 流程,并验证每个步骤是否按预期运行。
您可以使用 Google 账号关联演示版工具验证您的实现。
在该工具中,执行以下步骤:
- 点击使用 Google 账号登录按钮。
- 选择您要关联的账号。
- 输入服务 ID。
- (可选)输入您要请求访问权限的一个或多个范围。
- 点击开始演示。
- 当系统提示时,请确认您同意或拒绝关联请求。
- 确认您已被重定向到您的平台。
Учетные записи связаны с использованием неявного отраслевого стандарта OAuth 2.0 и потоков кода авторизации . Ваш сервис должен поддерживать авторизацию и конечные точки обмена токенами , совместимые с OAuth 2.0.
在隐式流程中,Google 会在用户的浏览器中打开您的授权端点。成功登录后,您将向 Google 返回一个长期访问令牌。现在,此访问令牌会包含在 Google 发送的每个请求中。
在授权代码流程中,您需要两个端点:
授权端点,用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期授权代码,以记录用户对所请求访问权限的同意情况。
令牌交换端点,负责两种类型的交换:
- 使用授权代码换取长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时,就会发生此交换。
- 将长期有效的刷新令牌换成短期有效的访问令牌。当 Google 需要新的访问令牌(因为现有访问令牌已过期)时,就会发生这种交换。
选择 OAuth 2.0 流程
虽然隐式流程更易于实现,但 Google 建议通过隐式流程签发的访问令牌永不过期。这是因为,在隐式流程中,令牌过期后,系统会强制用户重新关联其账号。如果您出于安全考虑需要令牌过期,我们强烈建议您改用授权码流程。
设计准则
本部分介绍了您为 OAuth 关联流程托管的用户屏幕的设计要求和建议。在 Google 应用调用该 API 后,您的平台会向用户显示登录 Google 页面和账号关联意见征求界面。同意关联账号后,系统会将用户重定向回 Google 的应用。

要求
- 您必须说明用户的账号将与 Google 相关联,而非 Google Home 或 Google 助理等特定 Google 产品相关联。
建议
建议您执行以下操作:
显示 Google 的隐私权政策。在同意屏幕上添加指向 Google 隐私权政策的链接。
要共享的数据。使用清晰简洁的语言告知用户 Google 需要哪些用户数据以及原因。
添加醒目的号召性用语。在用户同意页面上提供明确的号召性用语,例如“同意并关联”。这是因为用户需要了解他们需要与 Google 分享哪些数据才能关联账号。
可以取消。为用户提供返回或取消链接的途径,如果用户选择不进行关联。
明确的登录流程。确保用户有明确的 Google 账号登录方法,例如用户名和密码字段或使用 Google 账号登录。
能够解除关联。提供一种可让用户解除关联的机制,例如指向您平台上账号设置的网址。或者,您也可以添加指向 Google 账号的链接,以便用户管理其关联的账号。
能够更改用户账号。建议用户切换账号的方法。如果用户通常拥有多个账号,这种做法尤为有益。
- 如果用户必须关闭意见征求界面才能切换账号,请向 Google 发送可恢复的错误,以便用户可以使用 OAuth 关联和隐式流程登录所需的账号。
添加您的徽标。在意见征求页面上显示您的公司徽标。 按照您的样式准则放置徽标。如果您还想显示 Google 的徽标,请参阅徽标和商标。

Create the project
To create your project to use account linking:
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.
- Open the OAuth consent screen page of the Google APIs console.
- If prompted, select the project you just created.
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
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, имеет следующий процесс:
- Google открывает вашу конечную точку авторизации в браузере пользователя. Если поток для действия начался на голосовом устройстве, Google передает выполнение на телефон.
- Пользователь входит в систему, если он еще не вошел в систему, и предоставляет Google разрешение на доступ к своим данным с помощью вашего API, если он еще не предоставил разрешение.
- Ваш сервис создает код авторизации и возвращает его в Google. Для этого перенаправьте браузер пользователя обратно в Google, указав код авторизации, прикрепленный к запросу.
- Google отправляет код авторизации в конечную точку обмена токенами, которая проверяет подлинность кода и возвращает токен доступа и токен обновления . Токен доступа — это недолговечный токен, который ваша служба принимает в качестве учетных данных для доступа к API. Токен обновления — это долгосрочный токен, который Google может хранить и использовать для получения новых токенов доступа по истечении срока их действия.
- После того как пользователь завершил процесс привязки учетной записи, каждый последующий запрос, отправленный от Google, содержит токен доступа.
Обработка запросов на авторизацию
Когда вам необходимо выполнить привязку учетной записи с использованием потока кода авторизации OAuth 2.0, Google отправляет пользователя в вашу конечную точку авторизации с запросом, который включает следующие параметры:
Параметры конечной точки авторизации | |
---|---|
client_id | Идентификатор клиента, который вы назначили Google. |
redirect_uri | URL-адрес, на который вы отправляете ответ на этот запрос. |
state | Бухгалтерское значение, которое передается обратно в Google без изменений в URI перенаправления. |
scope | Необязательно: набор строк области действия, разделенных пробелами, которые определяют данные, для которых Google запрашивает авторизацию. |
response_type | Тип значения, возвращаемого в ответе. Для потока кода авторизации OAuth 2.0 тип ответа всегда — code . |
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 &scope=REQUESTED_SCOPES &response_type=code&user_locale=LOCALE
Чтобы конечная точка авторизации могла обрабатывать запросы на вход, выполните следующие действия:
- Убедитесь, что
client_id
соответствует идентификатору клиента, который вы назначили Google, и чтоredirect_uri
соответствует URL-адресу перенаправления, предоставленному Google для вашей службы. Эти проверки важны для предотвращения предоставления доступа непреднамеренным или неправильно настроенным клиентским приложениям. Если вы поддерживаете несколько потоков OAuth 2.0, также убедитесь, чтоresponse_type
равенcode
. - Проверьте, вошел ли пользователь в ваш сервис. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей службе.
- Создайте код авторизации, который Google будет использовать для доступа к вашему API. Код авторизации может быть любым строковым значением, но он должен однозначно представлять пользователя, клиента, для которого предназначен токен, а также время истечения срока действия кода, и его нельзя угадывать. Обычно вы выдаете коды авторизации, срок действия которых истекает примерно через 10 минут.
- Убедитесь, что URL-адрес, указанный параметром
redirect_uri
, имеет следующую форму:https://oauth-redirect.googleusercontent.com/r/
YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID - Перенаправьте браузер пользователя на URL-адрес, указанный параметром
redirect_uri
. Включите только что сгенерированный код авторизации и исходное неизмененное значение состояния при перенаправлении, добавив параметрыcode
иstate
. Ниже приведен пример результирующего 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_code , либо refresh_token . |
code | grant_type=authorization_code , этот параметр представляет собой код, который Google получил либо от вашей конечной точки входа в систему, либо от конечной точки обмена токенами. |
redirect_uri | grant_type=authorization_code , этот параметр представляет собой URL-адрес, используемый в первоначальном запросе авторизации. |
refresh_token | grant_type=refresh_token , этот параметр представляет собой токен обновления, который Google получил от вашей конечной точки обмена токенами. |
Обмен кодами авторизации для токенов доступа и токенов обновления.
После того как пользователь входит в систему и ваша конечная точка авторизации возвращает в Google кратковременный код авторизации, Google отправляет запрос на вашу конечную точку обмена токенами, чтобы обменять код авторизации на токен доступа и токен обновления.
Для этих запросов значение grant_type
— authorization_code
, а значение code
— это значение кода авторизации, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен кода авторизации на токен доступа и токен обновления:
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
Чтобы обменять коды авторизации для токена доступа и токена обновления, ваша конечная точка обмена токенами отвечает на запросы POST
, выполняя следующие шаги:
- Убедитесь, что
client_id
идентифицирует источник запроса как авторизованный источник и чтоclient_secret
соответствует ожидаемому значению. - Убедитесь, что код авторизации действителен, срок его действия не истек, а идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с кодом авторизации.
- Убедитесь, что URL-адрес, указанный в параметре
redirect_uri
, идентичен значению, используемому в первоначальном запросе авторизации. - Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с
{"error": "invalid_grant"}
в качестве тела. - В противном случае используйте идентификатор пользователя из кода авторизации для создания токена обновления и токена доступа. Эти токены могут быть любыми строковыми значениями, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадывать. Для токенов доступа также запишите срок действия токена, который обычно составляет час после выдачи токена. Токены обновления не имеют срока действия.
- Верните следующий объект JSON в текст ответа HTTPS:
{ "token_type": "Bearer", "access_token": "
ACCESS_TOKEN ", "refresh_token": "REFRESH_TOKEN ", "expires_in":SECONDS_TO_EXPIRATION }
Google хранит токен доступа и токен обновления для пользователя и записывает срок действия токена доступа. По истечении срока действия токена доступа Google использует токен обновления, чтобы получить новый токен доступа из вашей конечной точки обмена токенами.
Обмен токенов обновления на токены доступа
Когда срок действия токена доступа истекает, Google отправляет запрос на вашу конечную точку обмена токенами, чтобы обменять токен обновления на новый токен доступа.
Для этих запросов grant_type
— refresh_token
, а refresh_token
— это значение токена обновления, который вы ранее предоставили Google. Ниже приведен пример запроса на обмен токена обновления на токен доступа:
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
, выполняя следующие шаги:
- Убедитесь, что
client_id
идентифицирует источник запроса как Google и чтоclient_secret
соответствует ожидаемому значению. - Убедитесь, что токен обновления действителен и что идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с токеном обновления.
- Если вы не можете проверить все вышеперечисленные критерии, верните ошибку HTTP 400 Bad Request с
{"error": "invalid_grant"}
в качестве тела. - В противном случае используйте идентификатор пользователя из токена обновления для создания токена доступа. Эти токены могут быть любыми строковыми значениями, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадывать. Для токенов доступа также запишите срок действия токена, обычно через час после выдачи токена.
- Верните следующий объект JSON в текст ответа HTTPS:
{
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN ",
"expires_in":SECONDS_TO_EXPIRATION
}
Обработка запросов информации о пользователях
Конечная точка userinfo — это ресурс, защищенный OAuth 2.0, который возвращает утверждения о связанном пользователе. Реализация и размещение конечной точки userinfo не является обязательной, за исключением следующих случаев использования:
- Вход в связанную учетную запись с помощью Google One Tap.
- Простая подписка на AndroidTV.
После того как токен доступа был успешно получен из конечной точки вашего токена, 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 могла обрабатывать запросы, выполните следующие действия:
- Извлеките токен доступа из заголовка авторизации и верните информацию для пользователя, связанного с токеном доступа.
- Если токен доступа недействителен, верните ошибку HTTP 401 Unauthorized с использованием заголовка ответа
WWW-Authenticate
. Ниже приведен пример ответа об ошибке с информацией о пользователе: Если в процессе связывания возвращается ошибка 401 Unauthorized или любой другой неудачный ответ об ошибке, ошибка будет невосстановимой, полученный токен будет отброшен, и пользователю придется снова инициировать процесс связывания.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
Если токен доступа действителен, верните ответ HTTP 200 со следующим объектом JSON в теле ответа HTTPS:
Если ваша конечная точка userinfo возвращает успешный ответ HTTP 200, полученный токен и утверждения регистрируются в учетной записи Google пользователя.{ "sub": "
USER_UUID ", "email": "EMAIL_ADDRESS ", "given_name": "FIRST_NAME ", "family_name": "LAST_NAME ", "name": "FULL_NAME ", "picture": "PROFILE_PICTURE ", }ответ конечной точки с информацией о пользователе sub
Уникальный идентификатор, идентифицирующий пользователя в вашей системе. email
Адрес электронной почты пользователя. given_name
Необязательно: Имя пользователя. family_name
Необязательно: фамилия пользователя. name
Необязательно: Полное имя пользователя. picture
Необязательно: изображение профиля пользователя.
Проверка вашей реализации
您可以使用 OAuth 2.0 Playground 工具验证您的实现。
在该工具中,执行以下步骤:
- 点击配置 以打开 OAuth 2.0 配置窗口。
- 在 OAuth flow 字段中,选择 Client-side(客户端)。
- 在 OAuth 端点字段中,选择自定义。
- 在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
- 在第 1 步部分,不要选择任何 Google 范围。请将此字段留空或输入对服务器有效的范围(如果您不使用 OAuth 范围,则可以输入任意字符串)。完成后,点击授权 API。
- 在 Step 2 和 Step 3 部分中,完成 OAuth 2.0 流程,并验证每个步骤是否按预期运行。
您可以使用 Google 账号关联演示版工具验证您的实现。
在该工具中,执行以下步骤:
- 点击使用 Google 账号登录按钮。
- 选择您要关联的账号。
- 输入服务 ID。
- (可选)输入您要请求访问权限的一个或多个范围。
- 点击开始演示。
- 当系统提示时,请确认您同意或拒绝关联请求。
- 确认您已被重定向到您的平台。