Nodul LogoNodul

Аутентификация пользователей

Ключевое преимущество интеграции 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
  • Если вы используете режим инкогнито, пожалуйста, используйте обычную сессию браузера — режим инкогнито по умолчанию отключает хранение сторонних куки.