Внедрить сервер OAuth 2.0

Каждая интеграция Cloud-to-cloud должна включать механизм аутентификации пользователей.

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

На этой странице описано, как настроить сервер OAuth 2.0, чтобы он работал с вашей интеграцией Cloud-to-cloud .

Привязка аккаунта Google с помощью OAuth

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

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

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

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

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

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

Требования

1. Вы должны сообщить, что учетная запись пользователя будет связана с Google, а не с конкретным продуктом Google, таким как Google Home или Google Assistant.
2. У вас должно быть заявление об авторизации Google, например: «Выполняя вход, вы разрешаете Google управлять вашими устройствами». См . раздел «Авторизация управления устройствами Google» в правилах разработчика Google Home.
3. Вы должны предоставить пользователям возможность вернуться или отменить ссылку, если они решат не устанавливать ссылку.
4. Вам необходимо открыть страницу ссылок Web OAuth и убедиться, что у пользователей есть понятный способ входа в свою учетную запись Google, например поля для имени пользователя и пароля. Не используйте метод входа в Google (GSI), который позволяет пользователям подключаться без перехода на страницу ссылок Web OAuth. Это нарушение политики Google.

Рекомендации

Мы рекомендуем вам сделать следующее:

1. Отобразите Политику конфиденциальности Google. Включите ссылку на Политику конфиденциальности Google на экране согласия.

2. Данные для обмена. Используйте ясный и краткий язык, чтобы сообщить пользователю, какие данные требуются Google и почему.

3. Четкий призыв к действию. Укажите четкий призыв к действию на экране согласия, например «Согласитесь и разместите ссылку». Это связано с тем, что пользователям необходимо понимать, какими данными они должны поделиться с Google, чтобы связать свои учетные записи.

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

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

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

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

Поток кода авторизации

An OAuth 2.0 server implementation of the authorization code flow consists of two endpoints, which your service makes available by HTTPS. Первая конечная точка — это конечная точка авторизации, которая отвечает за поиск или получение согласия пользователей на доступ к данным. Конечная точка авторизации предоставляет пользовательский интерфейс входа вашим пользователям, которые еще не вошли в систему, и записывает согласие на запрошенный доступ. Вторая конечная точка — это конечная точка обмена токенами, которая используется для получения зашифрованных строк, называемых токенами, которые разрешают пользователю доступ к вашей службе.

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

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

1. Google открывает вашу конечную точку авторизации в браузере пользователя. Если поток для действия начался на голосовом устройстве, Google передает выполнение на телефон.
2. Пользователь входит в систему, если он еще не вошел в систему, и предоставляет Google разрешение на доступ к своим данным с помощью вашего API, если он еще не предоставил разрешение.
3. Your service creates an authorization code and returns it to Google. Для этого перенаправьте браузер пользователя обратно в Google, указав код авторизации, прикрепленный к запросу.
4. Google sends the authorization code to your token exchange endpoint, which verifies the authenticity of the code and returns an access token and a refresh token . Токен доступа — это недолговечный токен, который ваша служба принимает в качестве учетных данных для доступа к API. Токен обновления — это долгосрочный токен, который Google может хранить и использовать для получения новых токенов доступа по истечении срока их действия.
5. После того как пользователь завершил процесс привязки учетной записи, каждый последующий запрос, отправленный от Google, содержит токен доступа.

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

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

For example, if your authorization endpoint is available at https://myservice.example.com/auth , a request might look like the following:

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. Verify that the client_id matches the Client ID you assigned to Google, and that the redirect_uri matches the redirect URL provided by Google for your service. Эти проверки важны для предотвращения предоставления доступа непреднамеренным или неправильно настроенным клиентским приложениям. If you support multiple OAuth 2.0 flows, also confirm that the response_type is code .
2. Проверьте, вошел ли пользователь в ваш сервис. Если пользователь не вошел в систему, завершите процедуру входа или регистрации в вашей службе.
3. Создайте код авторизации, который Google будет использовать для доступа к вашему API. Код авторизации может быть любым строковым значением, но он должен однозначно представлять пользователя, клиента, для которого предназначен токен, а также время истечения срока действия кода, и его нельзя угадывать. Обычно вы выдаете коды авторизации, срок действия которых истекает примерно через 10 минут.
4. Confirm that the URL specified by the redirect_uri parameter has the following form:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. Redirect the user's browser to the URL specified by the redirect_uri parameter. Include the authorization code you just generated and the original, unmodified state value when you redirect by appending the code and state parameters. Ниже приведен пример результирующего URL-адреса:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Обработка запросов на обмен токенов

Конечная точка обмена токенами вашей службы отвечает за два типа обмена токенов:

• Обмен кодами авторизации для токенов доступа и токенов обновления.
• Обмен токенов обновления на токены доступа

Запросы на обмен токенов включают в себя следующие параметры:

Настройте способ отправки Google учетных данных на ваш сервер

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

По умолчанию Google отправляет учетные данные в теле запроса. If your authorization server requires the client credentials to be in the request header, you must configure your Cloud-to-cloud integration accordingly:

Зайдите в консоль разработчика

1. From the list of projects, click Open next to the project you want to work with.

2. Under Cloud-to-Cloud , select Develop .

3. Click Open next your integration.

4. Scroll down to the Permissions (optional) section and select the Have Google transmit Client ID and secret via HTTP basic auth header checkbox.

5. Click Save to save your changes.

Обмен кодами авторизации для токенов доступа и токенов обновления.

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

For these requests, the value of grant_type is authorization_code , and the value of code is the value of the authorization code you previously granted to 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

To exchange authorization codes for an access token and a refresh token, your token exchange endpoint responds to POST requests by executing the following steps:

1. Verify that the client_id identifies the request origin as an authorized origin, and that the client_secret matches the expected value.
2. Убедитесь, что код авторизации действителен и не истек, а также что идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с кодом авторизации.
3. Confirm that the URL specified by the redirect_uri parameter is identical to the value used in the initial authorization request.
4. If you can't verify all of the above criteria, return an HTTP 400 Bad Request error with {"error": "invalid_grant"} as the body.
5. В противном случае используйте идентификатор пользователя из кода авторизации для создания токена обновления и токена доступа. Эти токены могут иметь любое строковое значение, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадать. Для токенов доступа также запишите срок действия токена, который обычно составляет час после выдачи токена. Токены обновления не имеют срока действия.
6. Верните следующий объект JSON в текст ответа HTTPS:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

Обмен токенов обновления на токены доступа

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

For these requests, the value of grant_type is refresh_token , and the value of refresh_token is the value of the refresh token you previously granted to 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

To exchange a refresh token for an access token, your token exchange endpoint responds to POST requests by executing the following steps:

1. Verify that the client_id identifies the request origin as Google, and that the client_secret matches the expected value.
2. Убедитесь, что токен обновления действителен и что идентификатор клиента, указанный в запросе, соответствует идентификатору клиента, связанному с токеном обновления.
3. If you can't verify all of the above criteria, return an HTTP 400 Bad Request error with {"error": "invalid_grant"} as the body.
4. В противном случае используйте идентификатор пользователя из токена обновления для создания токена доступа. Эти токены могут иметь любое строковое значение, но они должны уникальным образом представлять пользователя и клиента, для которых предназначен токен, и их нельзя угадать. Для токенов доступа также запишите срок действия токена, обычно через час после выдачи токена.
5. Верните следующий объект 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 доступна по адресу 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	Необязательно: изображение профиля пользователя.