Удалённая аутентификация (Single Sign-On)

Последние изменения: 05.06.2026

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

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

Для таких сценариев используется удаленная аутентификация, или Single Sign-On (SSO). С ее помощью можно связать вход в центр поддержки с авторизацией на вашей стороне: клиент вводит логин и пароль на вашем сервисе, а затем получает доступ к центру поддержки без необходимости отдельно проходить авторизацию в Омнидеске. Настройки функционала находятся по пути: аккаунт администратора — раздел «Центр поддержки» — подраздел «Аутентификация».

Ниже разберем, чем отличается стандартная аутентификация от удаленной и как выполнять настройки в случае Single Sign-On (SSO).

1. Стандартная аутентификация от Омнидеска

a6ff9735318aad5c8b5d55eed2e60160.png

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

В качестве бонуса мы добавили опцию отображения центра поддержки только для авторизованных пользователей. В этом случае при переходе по ссылке центра поддержки отображается форма для авторизации:

092c6c2a03519ac1dc501901f8b8172c.png

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

2. Удаленная аутентификация

Настроить этот тип аутентификации сложнее, но он удобнее во многих аспектах. У него есть два основных применения: ограничение доступа к центру поддержки и избавление клиентов от двойной авторизации.

К примеру, вы хотите сделать закрытую базу знаний и размещать в ней материалы исключительно для платных клиентов. Для решения этой задачи нужно настроить Single Sign-On и скрыть центр поддержки от посторонних глаз с помощью опции «Центр поддержки доступен только авторизованным пользователям».

20b409cb1b0ba917f87a17c90eb9a518.png

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

Если же оставить неактивной опцию «Центр поддержки доступен только авторизованным пользователям», доступ к базе знаний и предложениям будет у всех, но войти смогут только ваши клиенты. В этом случае при нажатии на ссылку «Войти» (в правом верхнем углу центра поддержки) осуществляется переадресация на страницу, указанную в поле «URL удаленного входа».

Личный кабинет клиента на вашей стороне

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

Инструкция по JWT

1. Информация по JWT + пример использования JWT.

2. Поля, которые мы принимаем через JWT:

  • iat (обязательное) — Issued At (время, когда токен был сгенерирован);

  • email (обязательное) — email-адрес пользователя;

  • name (необязательное) — имя пользователя;

  • external_id (необязательное) — внешний id пользователя;

  • company_name (необязательное) — название компании пользователя;

  • company_position (необязательное) — должность пользователя;

  • remote_photo_url (необязательное) — url аватарки (допустимые форматы: jpg, jpeg, gif, png, webp);

  • exp (необязательное) — время, в течение которого запрос действителен.

3. Данные клиента необходимо передавать JWT-запросом по адресу: https://[yourcompany].omnidesk.ru/access/jwt?jwt=[jwt_payload], где вместо «jwt_payload» подставляется JWT, сформированный на вашей стороне.

⚠️ Если вы используете собственный поддомен, то первую часть адреса (https://[yourcompany].omnidesk.ru) нужно заменить на него.

4. При успешном JWT-запросе возвращается адрес для «принудительного логина» с кодом 200. Если произошла ошибка, ответ возвращается с кодом 401 и описанием ошибки.

Время жизни ссылки

Полученную ссылку для принудительного входа нельзя использовать как постоянную ссылку на центр поддержки. Она действует 1 минуту с момента получения и нужна только для разового входа пользователя.

Логика работы такая:

  • Пользователь нажимает кнопку или ссылку для перехода в центр поддержки на вашей стороне →
  • Вы отправляете JWT-запрос в Омнидеск →
  • В ответ Омнидеск возвращает временную ссылку для принудительного входа →
  • Вы перенаправляете пользователя по этой ссылке →
  • Пользователь попадает в центр поддержки уже авторизованным.

При следующем переходе в центр поддержки нужно снова отправить JWT-запрос и получить новую ссылку для входа.

Прочие нюансы

1. При включенной опции «Центр поддержки доступен только авторизованным пользователям» индексирование центра поддержки отключается вне зависимости от типа аутентификации.

2. Если выбран SSO и пользователь первый раз пишет на email-адрес службы поддержки, пароль в письме-уведомлении не указывается. Ссылка на обращение остается, но при переходе по ней пользователь направляется на вашу страницу авторизации (если пользователь еще не залогинен).

3. Данные пользователя, передаваемые вами через JWT (JSON Web Token, веб-маркер JSON), затирают данные, которые хранятся у нас. Поэтому, если не нужно изменять данные пользователя, в JWT-запросе следует передавать только email-адрес.

4. Если для идентификации клиента вы используете уникальный ID, мы сохраняем его в профиле пользователя, когда не находим ID из запроса, но находим email-адрес. В такой ситуации для найденного адреса прописывается external_id из вашего запроса.

5. Если вы настраиваете удаленную аутентификацию, то у авторизованного пользователя при создании обращения поля «Полное имя» и «Email-адрес» будут скрыты в форме отправки запроса.

Помогла ли вам статья?