Аутентификация пользователей
Ключевое преимущество интеграции Nodul — простота аутентификации. Пользователи входят через ваше приложение, получая специальный токен для доступа к функциям Nodul. Система использует JSON Web Token (JWT), защищённый уникальным приватным ключом от Nodul. JWT содержит данные пользователя из вашей системы. После проверки подписи JWT платформой Nodul пользователь получает клиентские привилегии и может работать с интеграциями в рамках своей учётной записи.
Приватный ключ подписи
Прежде чем генерировать JWT, вам понадобится действительный ключ подписи от Nodul. Обратитесь в службу поддержки для получения ключа.
Храните этот ключ в безопасном месте — он будет использоваться для проверки аутентификации пользователей в вашем приложении.
Создание и подпись JWT
Теперь, когда у вас есть ключ подписи, вы можете создать и подписать JSON Web Token (JWT). Для этого можно использовать одну из библиотек, подходящих для вашего бэкенда.
JWT, который вы генерируете для пользователя, должен иметь следующие свойства:
-
Header должен указывать алгоритм шифрования и выглядеть примерно так:
{ "alg": "RS256", "typ": "JWT" }Поддерживаемые алгоритмы JWT:
- RS256, RS384, RS512
- ES256, ES256K, ES384, ES512
- PS256, PS384, PS512
-
Приватный ключ подписи, выданный Nodul
-
Payload со следующими данными:
-
tenant_id— обязательное числовое поле. Предоставляется платформой Nodul. -
user_id— обязательное поле. ID пользователя в вашей организации. Уникальное строковое значение, однозначно идентифицирующее пользователя. -
plan_id— опциональное числовое поле. ID тарифного плана, который будет установлен пользователю если это первая авторизация пользователя на платформе. В дальнейшем это поле заполнять не нужно. -
no_personal_space— опциональное булево поле. Еслиtrue, пользователь будет создан без личного пространства. -
grant_access— опциональный массив, который позволяет назначить пользователя в одно или несколько существующих пространств с указанными ролями. Обязательно, еслиno_personal_spaceустановлено вtrue. -
exp— обязательное числовое поле. Токен считается действительным до достижения указанной метки времени.Пример JWT
Payload{ "tenant_id": 1, "user_id": "1", "plan_id": 35, "no_personal_space": true, "grant_access": [{ "space_id": 2, "role_id": 2 }], "exp": 1768417200 }
-
В этом примере:
- Пользователь принадлежит тенанту 1.
- Пользователь будет создан без личного пространства.
- Поскольку
no_personal_spaceравноtrue, полеgrant_accessобязательно. - Пользователь получит доступ к пространству с ID 2 и будет назначен на роль с ID 2.
- Токен считается действительным до
1768417200.
Доступные роли
Nodul предоставляет модель доступа на основе ролей для пользователей в каждом пространстве.
Каждая роль определяет, какие действия может выполнять пользователь.
| Роль | Описание |
|---|---|
Admin (role_id: 1) | Имеет полный доступ к пространству и всем его настройкам. Может создавать, редактировать и удалять сценарии, управлять пользователями и изменять настройки пространства. Только один администратор может существовать в пространстве. Создаётся автоматически при создании нового пространства. |
Manager (role_id: 2) | Имеет почти те же разрешения, что и Admin, но не может добавлять или удалять пользователей из пространства. |
No-code (role_id: 3) | Может создавать, редактировать, удалять, активировать/деактивировать и перемещать сценарии между папками. Не имеет доступа к управлению папками, пользователями или пространством. |
Read only (role_id: 4) | Может просматривать и запускать сценарии. Не имеет доступа к управлению папками, пользователями или пространством. |
Создания JWT-токена достаточно для регистрации или авторизации пользователя на платформе Nodul. Используйте этот токен в методе SDK configure. Если пользователь новый, он будет автоматически зарегистрирован и авторизован.
⚠️ Известные ограничения браузеров (Safari и режим инкогнито)
При использовании стандартного потока аутентификации внутри iframe некоторые браузеры — в частности, Safari и режим инкогнито/приватный режим в Chrome — могут блокировать сторонние куки. Поскольку наша авторизация зависит от куки внутри iframe, это может приводить к неудачным попыткам входа.
Рекомендации:
- Если вы используете Safari, вы можете:
- Добавить родительский домен iframe в список доверенных сайтов
- Или отключить «Предотвращать межсайтовое отслеживание» в настройках Safari
- Если вы используете режим инкогнито, пожалуйста, используйте обычную сессию браузера — режим инкогнито по умолчанию отключает хранение сторонних куки.