Конфигурация и технические детали OAuth2.0

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

Примечание: поток клиентских учетных данных несколько отличается от потока кода авторизации. Шаги 1 и 2 не относятся к потоку клиентских мандатов.

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

:::(Warning) (On-Prem Services) Конечные точки Authorize и Token должны быть доступны в облаке, чтобы Tulip мог выполнить аутентификацию для коннекторов :::

Tulip инициирует процесс аутентификации при тестировании коннектора или запуске функции коннектора в приложении.

1. Перенаправление на сервер авторизации:

Приложение Tulip перенаправляет пользователя на сервер авторизации (AS) вместе с определенными параметрами, включая response_type (установленный в "code" для Authorization Code Flow), client_id (назначенный в UI коннектора), redirect_uri (предопределенный Tulip), scope и audience (установленные в UI), а также state (случайная строка для защиты от атак Cross-Site Request Forgery).

Пример:GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=SCOPE&audience=AUDIENCE&state=STATE

2. Пользователь дает согласие:

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

:::(Warning) (Примечание) В конфигурации коннектора give элемент управления "Пропускать запрос на согласие пользователя" позволяет управлять атрибутом запроса на авторизацию. Если этот элемент управления отключен, будет использоваться значение consent, если включен - login.

Если требуются дополнительные значения атрибута prompt, напишите на support@tulip.co, и мы включим дополнительные опции для этого свойства. :::

3. Код авторизации:

Если пользователь дает согласие, сервер авторизации генерирует код авторизации и перенаправляет пользователя обратно на Tulip вместе с кодом авторизации. Параметр state также включается, чтобы клиент мог проверить целостность ответа. Этот параметр состояния должен совпадать с параметром состояния, переданным на шаге 1.

Пример перенаправления на URI перенаправления клиента:

REDIRECT_URI?code=AUTHORIZATION_CODE&state=STATE

4. Запрос токена:

Теперь у клиента есть код авторизации, и он использует его для безопасного межсерверного запроса к конечной точке токена сервера авторизации. Клиент указывает grant_type (установленный на "authorization_code"), client_id, client_secret (секрет, известный только клиенту и серверу авторизации), redirect_uri и код авторизации.

Пример запроса токена:

`` POST /token Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&client_id=CLIENT_ID&client_secret=CLIENT_SECRET ```

5. Ответ маркера доступа:

Если код авторизации действителен, сервер авторизации отвечает маркером доступа и, опционально, маркером обновления. Токен доступа используется клиентом для аутентификации при выполнении запросов к защищенному API от имени пользователя.

Пример ответа на токен:

{ "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "REFRESH_TOKEN", "scope": "SCOPE" }

6. Доступ к серверу ресурсов:

Теперь Tulip может использовать полученный токен доступа для выполнения авторизованных запросов к серверу ресурсов (API) от имени пользователя. Токен доступа обычно включается в заголовок Authorization HTTP-запроса.

Пример запроса к API:GET /api/resource Авторизация: Bearer ACCESS_TOKEN

Управление сроком действия токена с помощью обновляемых токенов

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

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

Как Tulip управляет обновлением токенов

Когда Tulip обнаруживает, что срок действия маркера доступа истек, он автоматически пытается использовать связанный с ним маркер обновления для получения нового маркера. Основная цель - свести к минимуму повторную аутентификацию пользователей. Следующие шаги описывают логику, выполняемую Tulip:

1. Обнаружение истечения срока действия:

2. Tulip идентифицирует токен с истекшим сроком действия на основе его атрибута expires_in, полученного на шаге 5 потока аутентификации.

3. Попытка потока токенов:

4. Tulip инициирует поток токенов, используя тип гранта refresh_token, заменяя тип гранта authorization_code, использованный в начальном потоке аутентификации.

5. Проверка токена:

6. Если новый токен получен, Tulip сохраняет его и приступает к выполнению запрошенной пользователем функции коннектора.

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

7. Обработка отсутствия токена:

8. Если новый токен не предоставлен, Tulip предлагает пользователю в плеере пройти аутентификацию, инициируя весь процесс аутентификации.

9. По завершении выполняется функция коннектора и возвращаются данные.

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

Дополнительная информация

• Введение в хосты коннекторов Tulip
• Создание моментальных снимков коннектора
• Объяснение OAuth2.0