Обзор способов аутентификации в Spotnana
СОДЕРЖАНИЕ
Spotnana предлагает разные способы аутентификации, чтобы партнеры могли безопасно интегрироваться с нашей платформой. В этой документации вы найдете обзор всех поддерживаемых методов аутентификации Spotnana и подробное описание каждого из них. Здесь показано, как Spotnana проверяет и разрешает доступ пользователям к защищённым ресурсам организации (то есть к данным компании пользователя на платформе Spotnana).
Основные компоненты
Перед началом работы ознакомьтесь с этим списком — здесь объясняются ключевые компоненты системы, которые упоминаются в документации.
- Spotnana UI(Пользовательский интерфейс Spotnana) Это веб-приложение Spotnana (онлайн-система бронирования) или мобильное приложение Spotnana. В данном контексте речь идет о странице входа, которая запускает процесс аутентификации при входе пользователя или создании новой учетной записи.
- Сервер Spotnana Это серверная часть Spotnana, которая отвечает за аутентификацию (например, разрешает доступ к ресурсам и безопасно хранит данные пользователей).
- Партнерский UI (Пользовательский интерфейс партнера) Это интерфейс (то есть клиентское приложение), через который партнеры получают доступ к платформе Spotnana. Например, при аутентификации через iFrame платформа Spotnana встраивается в интерфейс партнера, и пользователи заходят в Spotnana через этот UI.
- Сервер партнера Это один или несколько серверов, которые партнеры используют для интеграции с Spotnana.
- Spotnana IdP (Провайдер идентификации Spotnana) Внутренний сервис Spotnana для управления учетными записями пользователей и их авторизацией.
- IdP партнера Сторонние провайдеры идентификации (IdP), которыми пользуются партнеры. К примеру, Google или Azure.
- OBT Онлайн-система бронирования Spotnana (OBT), доступная по адресу https://app.spotnana.com/
- Токен субъекта При аутентификации через iFrame (или обмен токенами) токен субъекта подтверждает личность пользователя. С помощью этого токена система получает информацию о пользователе и дает ему доступ к платформе Spotnana.
- Токен доступа Это временный ключ (OAuth), который приложение-партнер использует для доступа к защищённым ресурсам от имени пользователя. Такой токен позволяет делать запросы к API без передачи пароля пользователя.
- Refresh token (токен обновления) Долгоживущий токен, с помощью которого можно получить новый токен доступа без повторной аутентификации пользователя. Обычно он выдается вместе с токеном доступа при первом входе.
- Client credentials (клиентские данные) Данные, которые выдаются пользователям для прямого подключения к API Spotnana (например, уникальные
clientIdиclientSecret). - PID (Персональный идентификатор) Уникальный идентификатор пользователя, с помощью которого сервер Spotnana находит информацию о нем.
orgIdУникальный идентификатор организации пользователя, который присваивается Spotnana.tmcIdУникальный идентификатор, который Spotnana выдает для TMC (туристической компании).
Поддерживаемые способы аутентификации
Spotnana поддерживает следующие способы аутентификации:
- Аутентификация по паролю
- Аутентификация через IdP
- Аутентификация через API
- Аутентификация через iFrame
- Аутентификация по коду авторизации
- Аутентификация «машина-машина» (M2M)
Аутентификация по паролю
При аутентификации по паролю Spotnana UI (то есть страница входа или регистрации в OBT) запускает и управляет процессом входа через серверы Spotnana. В зависимости от того, входит ли пользователь с уже существующим профилем или создает новый, процесс будет отличаться. Оба варианта подробно разобраны ниже с помощью диаграмм последовательности.
Существующий пользователь
Ниже показаны диаграмма последовательности и шаги, которые объясняют, как Spotnana UI взаимодействует с сервером для аутентификации уже зарегистрированного пользователя.

Рис.: Диаграмма последовательности, показывающая процесс аутентификации по паролю для существующих пользователей.
| Шаг | Процесс |
|---|---|
| Пользователь с существующим аккаунтом входит через OBT или мобильное приложение Spotnana, используя свой email. | |
| 1 |
|
| 2 |
|
| 3 |
|
Новый пользователь
Ниже показаны диаграмма последовательности и шаги, которые объясняют, как Spotnana UI взаимодействует с сервером для аутентификации нового пользователя (или для сброса пароля существующего пользователя).

Рис.: Диаграмма последовательности, показывающая процесс аутентификации по паролю для новых пользователей.
Шаг | Процесс |
|---|---|
Новый пользователь вводит свой email на странице входа в OBT Spotnana и нажимает Next. | |
1 |
|
1 a | Пользователь придумывает новый пароль и нажимает Next. |
2 |
|
| 3 |
|
| 4 |
|
Аутентификация через IdP
Spotnana поддерживает вход через IdP, такие как Google, Azure и собственные IdP на базе OpenID Connect или SAML. Ниже показаны диаграмма последовательности и шаги для аутентификации через IdP.

Рис.: Диаграмма последовательности, показывающая процесс аутентификации через IdP.
| Шаг | Процесс |
|---|---|
| Пользователь входит через OBT или мобильное приложение Spotnana, используя свой email. | |
| 1 |
|
| 2 | Spotnana UI перенаправляет запрос к Spotnana IdP. |
| 3 | Spotnana IdP перенаправляет запрос к IdP партнера. Это запускает процесс аутентификации через IdP. Примечание: При каждом перенаправлении возвращается статус 302, чтобы показать, что запрос был отправлен на другой URL. |
| 4 | Устанавливается соединение между Spotnana IdP и IdP партнера, чтобы убедиться, что пользователь прошёл аутентификацию у партнера. Примечание: В ходе этого соединения Spotnana IdP отправляет |
| 5 | IdP партнера успешно аутентифицирует пользователя. Примечание: После этого шага профиль пользователя должен пройти проверку bearer token. |
| 5 a | После успешной аутентификации IdP партнера отправляет ответ в Spotnana IdP. |
| 5 b | Spotnana IdP генерирует уникальный код для профиля пользователя и отправляет его в Spotnana UI. |
| 6 |
Примечание: Успешное создание bearer token означает, что пользователь прошёл аутентификацию и может пользоваться Spotnana. |
| 7 |
|
Аутентификация через API
Партнеры, которые используют API Spotnana для подключения к платформе, могут получить bearer token для своих пользователей через специальную конечную точку аутентификации. Ниже показана диаграмма последовательности для такого сценария.

Рис.: Диаграмма последовательности, показывающая процесс аутентификации через API.
| Шаг | Процесс |
|---|---|
| 1 | Пользователь API делает POST запрос к Вот пример запроса cURL, который можно использовать для обращения к curl -i -X POST \
https://api.spotnana.com/get-auth-token \
-H 'Content-Type: application/json' \
-d '{
"clientId": "sample-apiuser@tmcorg.com",
"clientSecret": "<password>"
}'Примечание: Замените значения |
| 2 |
|
После получения bearer token все следующие запросы к API Spotnana (например, к Trip APIs) должны содержать этот токен в заголовке для авторизации.
Примечание: Конечная точка get-auth-token(clientId, clientSecret) ограничена 100 запросами за 5 минут.Аутентификация через iFrame
Встраивание через iFrame — это когда партнеры интегрируют интерфейс Spotnana в свой UI, и пользователи заходят в Spotnana через интерфейс партнера. В этом случае аутентификация пользователя строится на обмене токенами между системами партнера и Spotnana.
Примечание: при аутентификации через iFrame пользователь, который входит, будет называться caller. Это сделано для поддержки сценариев, когда API/машинный пользователь входит и запрашивает токен доступа для другого пользователя. Такой API/машинный пользователь может использовать учетные данные администратора TMC для прямого подключения к серверу Spotnana. Поэтому мы используем термин caller как обобщение — это может быть как обычный пользователь, так и API/машинный пользователь, который запрашивает токен для другого.
Ниже показана диаграмма последовательности, как происходит обмен токенами между Spotnana и серверами партнера.
Рис.: Диаграмма последовательности, показывающая аутентификацию через iFrame с обменом токенами.
| Шаг | Процесс |
|---|---|
Caller входит через интерфейс партнера. | |
| 1 | Партнерский UI отображает Spotnana UI во встроенном iFrame. |
| 2 | Spotnana UI отправляет запрос в UI партнера через post message, чтобы получить токены. В запросе указывается type=TOKEN_EXCHANGE_REQUEST. |
| 3 | Партнерский UI отправляет API-запрос на сервер партнера, чтобы получить OAuth-токен и запустить следующий этап аутентификации. |
| 3 a | Сервер партнера обращается к серверу Spotnana, передавая учетные данные пользователя и токен субъекта. Spotnana проверяет, что запрос отправлен от API/машинного пользователя. |
| 3 b |
|
| 3 c |
|
| 4 | Партнерский UI отправляет токен в Spotnana UI через post message с |
| 5 |
Примечание: Успешное создание bearer token означает, что пользователь прошёл аутентификацию и может пользоваться Spotnana. |
| 6 |
|
Аутентификация по коду авторизации
Ниже показана диаграмма последовательности, как происходит аутентификация с помощью кода авторизации.

Рис.: Диаграмма последовательности, показывающая аутентификацию по коду авторизации.
| Шаг | Процесс |
|---|---|
| 1 | Партнерский UI обращается к серверу партнера, чтобы получить код авторизации для caller. Код возвращается в UI партнера. |
| 2 | Партнерский UI отправляет запрос в Spotnana UI через специальный redirect URL, в котором передаются |
| 3 | Spotnana UI делает POST запрос к серверу Spotnana по адресу |
| 3 a |
|
| 3 b | Сервер Spotnana генерирует access token и refresh token и отправляет их в Spotnana UI. |
| 4 |
Примечание: Успешное создание bearer token означает, что пользователь прошёл аутентификацию и может пользоваться Spotnana. |
| 5 |
|
Примечание: Этот способ аутентификации не подходит, если администратор TMC разрешает нескольким пользователям входить под одним email.
Аутентификация «машина-машина» (M2M)
M2M-аутентификация подходит, если клиентское приложение обращается к стороннему callback URL для генерации accessToken для пользователя. Ниже показана диаграмма последовательности для этого сценария.

Рис.: Диаграмма последовательности, показывающая процесс M2M-аутентификации.
| Шаг | Процесс |
|---|---|
Публичные ключи всех приложений, участвующих в аутентификации, синхронизируются между сервером Spotnana и Spotnana IdP. Позже они используются для проверки токена доступа. | |
| 1 | Сервер партнера отправляет API-запрос на |
| 2 |
|
| 3 |
|
Статья помогла?
Отлично!
Спасибо за ваш отзыв
Извините, что не удалось помочь!
Спасибо за ваш отзыв
Комментарий отправлен
Мы ценим вашу помощь и постараемся исправить статью