Главная / Документация / ДоступЕдиный вход (OIDC): подключение провайдераКак подключить вход через Keycloak, Azure AD, Okta, Google и другие OIDC-провайдеры: адрес возврата, секрет, роль по умолчанию и проверка входа.Обновлено 29.10.2026OIDC (OpenID Connect) - вход в volrix.pm через внешнего провайдера учетных записей: Keycloak, Azure AD (Entra ID), Okta, Google или любой совместимый. На странице входа появляется кнопка «Войти через <название провайдера>», а пароль и второй фактор человек вводит на стороне провайдера. OIDC можно включить вместе с LDAP / AD.**Где находится:** «Администрирование» → «Доступ» → «Вход в систему», вкладка «Единый вход (OIDC)». Нужно право «OIDC SSO - Настройки OIDC SSO»; чтобы в меню был виден сам пункт «Вход в систему», нужно еще «LDAP / AD - Настройки LDAP / AD». По умолчанию оба права только у администратора системы.Что подготовить

Рабочий адрес системы, например https://pm.example.ru. Он задается в «Администрирование» → «Настройки продукта» → «Сертификаты TLS», блок «Адрес системы»; если там пусто, берется FRONTEND_URL из файла .env каталога установки. Из этого адреса сервер собирает адрес возврата.

HTTPS: большинство провайдеров принимают адрес возврата только по https (HTTPS).

Доступ с сервера volrix.pm к провайдеру: описание провайдера, обмен кода на токен и ключи подписи запрашивает сервер, а не браузер.

Тестового пользователя у провайдера с заполненным email.

Рабочий вход локального администратора на время проверки.

Свободное место в лицензии: каждый человек, которого система создаст при первом входе, занимает одно место (Лицензия).

Адрес возвратаВ синей плашке вверху страницы показан адрес возврата (redirect URI), который нужно зарегистрировать у провайдера. Плашка собирает его из адреса, по которому вы открыли страницу, а сервер при входе берет адрес системы из настроек. Если администрирование открыто не по рабочему адресу (например, по IP и порту 3000), значения разойдутся. Регистрируйте у провайдера адрес такого вида, где https://pm.example.ru - адрес системы:https://pm.example.ru/api/v1/auth/sso/oidc/callbackСмена «Адреса системы» меняет и адрес возврата: после нее зарегистрируйте новый адрес у провайдера, иначе вход остановится с ошибкой redirect_uri. Приложение volrix для компьютера и телефона входит через системный браузер и того же провайдера; отдельный адрес возврата для него у провайдера регистрировать не нужно.Поля настроек OIDC: адрес возврата, параметры клиента и claims. Секрет скрыт.

OIDC: адрес возврата, параметры клиента и claims. Секрет скрыт.

Подключение

Поле

Что указать

Пример

«Включить OIDC SSO»

Показывает кнопку входа через провайдера на странице входа.

включить после проверки

«Название провайдера»

Текст на кнопке «Войти через ...». По умолчанию «OIDC».

Keycloak

«Issuer URL»

Адрес провайдера; сервер добавляет к нему /.well-known/openid-configuration. Кнопки «Примеры» подставляют шаблон и название для Keycloak, Okta, Azure AD и Google.

https://sso.example.ru/realms/company

«Client ID»

Идентификатор клиента, зарегистрированного у провайдера.

volrix

«Client Secret»

Секрет клиента. Хранится зашифрованным; при открытии страницы поле пустое, и если его не трогать, при сохранении остается прежний секрет.

«Scopes»

Запрашиваемые области через пробел; openid обязателен.

openid email profile

Шаблоны Issuer URL: Keycloak - https://<сервер>/realms/<realm>; Azure AD - https://login.microsoftonline.com/<tenant_id>/v2.0; Okta - https://<tenant>.okta.com; Google - https://accounts.google.com. Завершающий слеш в адресе при сохранении убирается.Claims из id_token

Поле

По умолчанию

Для чего

«Внешний ID (sub)»

sub

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

«Email»

Email учетной записи. Без него новую учетную запись не создать.

«ФИО»

name

ФИО в профиле.

«Username»

preferred_username

Запасной вариант ФИО, если name пуст.

Значения читаются только из id_token - дополнительные данные у провайдера не запрашиваются. Если провайдер не кладет email или name в id_token, включите это на его стороне: в Keycloak - у маппера клиента параметр «Add to ID token»; в Azure AD - необязательное утверждение email в регистрации приложения. ФИО и email берутся при создании учетной записи и при следующих входах через OIDC не обновляются.Поведение

Поле

Что делает

Рекомендация

«Автосоздание учеток»

Неизвестный человек получает учетную запись при первом входе. Если выключено, войдут только те, кто уже есть в системе; остальные вернутся на страницу входа с сообщением «SSO: user_not_found».

Включить, если провайдер пускает только сотрудников

«Связывать по email»

Если учетная запись с таким email уже есть (заведена вручную или создана через LDAP), вход привязывается к ней, и дубль не создается.

Включать, только если провайдер подтверждает адреса почты: иначе человек, указавший у провайдера чужой email, войдет под чужой учетной записью

«Роль по умолчанию»

Код роли для новых учетных записей (user, expert), а не название. Неизвестный код, в том числе код вашей собственной роли, заменяется на user. Роль «Системный администратор» (admin_system) указать нельзя: сохранение откажет, а системных администраторов назначают вручную.

user

Коды системных ролей: user - Пользователь, expert - Эксперт, pm - Руководитель проекта, project_admin - Администратор проекта, eol - Единое ответственное лицо, finance - Финансист, office - Канцелярия, auditor - Аудитор, contract_manager - Контрактный менеджер, program_manager - Менеджер программы, portfolio_admin - Администратор портфеля, signer - Подписант, poa_approver - Уполномоченный по доверенностям. Что дает каждая роль - в статье Роли и доступы.Регистрация клиента у провайдераПример для Keycloak: в нужном realm откройте «Clients» → «Create client». Тип - OpenID Connect, Client ID - например volrix. Включите «Client authentication» (конфиденциальный клиент) и «Standard flow». В «Valid redirect URIs» впишите адрес возврата из раздела выше. Секрет возьмите на вкладке «Credentials». Issuer URL - https://<сервер Keycloak>/realms/<realm>.Для Azure AD: зарегистрируйте приложение, добавьте redirect URI типа Web, создайте секрет в «Certificates & secrets». Issuer URL - https://login.microsoftonline.com/<tenant_id>/v2.0.volrix.pm использует Authorization Code с PKCE и передает секрет в теле запроса токена (client_secret_post) - провайдер должен это разрешать.Порядок подключения

Зарегистрируйте клиента У провайдера создайте клиента с адресом возврата от адреса системы, получите Client ID и секрет.

Заполните подключение Укажите «Название провайдера», «Issuer URL», «Client ID», «Client Secret» и «Scopes».

Проверьте discovery Нажмите «Проверить discovery». Сервер запросит описание провайдера. Успех - «OK» и адреса authorize и token; ошибка - текст причины. Успех означает только, что провайдер доступен с сервера: Client ID и секрет здесь не проверяются.

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

Включите и сохраните Включите «Включить OIDC SSO» и нажмите «Сохранить». Появится «Настройки OIDC сохранены», значок в заголовке сменится на «Включено».

Проверьте вход В другом браузере или в окне инкогнито откройте страницу входа - появится кнопка «Войти через <название>». Нажмите ее, войдите у провайдера тестовым пользователем. Браузер вернется в volrix.pm уже под этим человеком.

Проверьте учетную запись Откройте профиль: ФИО и email должны совпадать с данными провайдера. В «Администрирование» → «Доступ» → «Пользователи» убедитесь, что не появился дубль, и назначьте рабочие роли (Роли и доступы). Входы и ошибки входа записываются в журнал аудита.

Как находится учетная запись

По внешнему ID Сначала - по значению sub среди учетных записей, которые уже входили через OIDC.

По email Если не найдено и включено «Связывать по email» - по адресу почты. Найденная учетная запись переводится на вход через OIDC и в следующий раз находится по sub.

Создание Если не найдено и включено «Автосоздание учеток» - создается новая учетная запись с ролью по умолчанию; она занимает место лицензии.

Отказ Иначе вход отклоняется: страница входа с сообщением «SSO: user_not_found».

Двухфакторная аутентификация volrix.pm при входе через OIDC не запрашивается, политика «Двухфакторная аутентификация» на таких пользователей не распространяется - второй фактор настраивается у провайдера.

Выключенная в карточке учетная запись (переключатель «Активен») не войдет и через OIDC: вход заканчивается сообщением «Учетная запись недоступна».

Требования к паролю и блокировка из раздела Пароли и блокировка на вход через OIDC не действуют: пароль проверяет провайдер.

Если не получаетсяОшибки, которые провайдер или сервер вернули до создания сеанса, страница входа показывает в красной строке с началом «SSO: ...». Ошибки создания учетной записи (нет email, email занят, нет мест, учетная запись недоступна) браузер показывает коротким текстом на пустой странице, без формы входа.

Что видно

Причина и что сделать

Провайдер пишет redirect_uri mismatch или Invalid parameter: redirect_uri

Зарегистрированный адрес не совпадает с адресом системы плюс /api/v1/auth/sso/oidc/callback. Сверьте протокол, домен, порт и путь; проверьте «Адрес системы» на экране «Сертификаты TLS» и FRONTEND_URL в .env.

«Проверить discovery» выдает ошибку

Неверный «Issuer URL» (для Keycloak нужен путь /realms/<realm>) или сервер volrix.pm не выходит к провайдеру: DNS, прокси, межсетевой экран.

После нажатия кнопки - ответ «OIDC недоступен: ...»

Сервер не получил описание провайдера при входе. Проверьте доступность Issuer URL с сервера volrix.pm.

«SSO: Token exchange отказан: 401 ...»

Неверный «Client Secret» или «Client ID», либо клиент у провайдера не конфиденциальный. Введите секрет заново и сохраните.

«SSO: id_token невалиден: ...»

Не тот «Client ID» (токен выпущен для другого клиента), issuer провайдера отличается от ожидаемого или сильно расходятся часы сервера. Проверьте Client ID и время на сервере.

«Сессия входа не найдена, начните вход заново» или «SSO: State cookie невалиден или просрочен»

Вход длился больше 10 минут, либо система открыта не по адресу системы, либо адрес системы начинается с https, а сайт открыт по http. Откройте систему по рабочему адресу и повторите.

«SSO: user_not_found»

Учетной записи нет, а автосоздание выключено (или выключено связывание по email). Включите автосоздание либо заведите пользователя с тем же email и включите связывание.

«OIDC не вернул email - не можем создать аккаунт»

В id_token нет claim из поля «Email». Добавьте email в id_token у провайдера или укажите другое имя claim.

«Email ... уже используется локально»

Связывание по email выключено, а учетная запись с таким адресом уже есть. Включите «Связывать по email» (если провайдер подтверждает почту) или измените email у существующей записи.

Сообщение о лимите пользователей лицензии

Все места лицензии заняты. Заблокируйте тех, кто уже не работает, или расширьте лицензию (Лицензия).

«Учетная запись недоступна»

В карточке человека выключен «Активен» или у него нет учетной записи. Включите «Активен» в «Администрирование» → «Доступ» → «Пользователи».

Сохранение отвечает, что роль по умолчанию не может быть «Системный администратор»

Выберите обычную роль, например user. Системных администраторов назначайте вручную в карточке.

У человека две учетные записи

Email у провайдера отличается от email в volrix.pm, поэтому связывание не сработало и создана новая запись. Приведите адреса к одному; лишнюю запись выключите.

После входа слишком широкие права

Проверьте «Роль по умолчанию» и роли учетной записи, к которой вход привязался по email.

LDAP / AD и Kerberos

HTTPS

Роли и доступы

Вход по доменной учетной записи.Сертификат и адрес системы.Какие роли назначить после первого входа.

Безопасность и закрытый контур

Интеграции и REST API