Аутентификация OpenID Connect в 1С: как включить и настроить

OpenID Connect (OIDC) — это протокол аутентификации поверх OAuth 2.0, который позволяет пользователям входить в информационную базу 1С через внешнего провайдера идентификации: корпоративный Keycloak, Active Directory Federation Services, «1С:Контрагент»-экосистему и другие сервисы. Платформа 1С:Предприятие поддерживает такой сценарий начиная с версии 8.3.17, и настройка выполняется без изменения конфигурации — средствами публикации и файла настроек веб-сервера.

Типовая задача выглядит так: сотрудники уже имеют учётные записи в корпоративном каталоге или облачном сервисе, и требуется, чтобы вход в 1С происходил через единый логин-пароль (или даже через корпоративную карточку/сертификат), без отдельного пароля информационной базы. OpenID Connect решает именно эту задачу: аутентификацией занимается провайдер, а 1С лишь доверяет выданному им токену и сопоставляет его с пользователем информационной базы.

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

Предварительные условия: что должно быть готово до настройки

Первое условие — версия платформы. Поддержка OpenID Connect появилась в платформе 1С:Предприятие 8.3.17, поэтому на более ранних релизах механизм недоступен в принципе. Рекомендуется использовать актуальные релизы линейки 8.3, так как в них исправляются ошибки механизма аутентификации и расширяется совместимость с провайдерами.

Второе условие — публикация информационной базы на веб-сервере. OpenID Connect работает только при доступе через веб-клиент или тонкий клиент по HTTP/HTTPS, то есть база должна быть опубликована на Apache или IIS. Файловая база, открываемая напрямую с диска, и клиент-серверный доступ по протоколу tcp для этого сценария не подходят.

Третье условие — доступный OIDC-провайдер. Это может быть развёрнутый внутри контура Keycloak, корпоративный AD FS, либо внешний сервис. Провайдер должен быть доступен по HTTPS как с рабочих мест пользователей, так и (для части проверок) с сервера, где опубликована 1С. Самоподписанные сертификаты без добавления в доверенные хранилища — частая причина неработающего входа.

Регистрация 1С как клиента у провайдера OpenID Connect

Прежде чем настраивать 1С, её нужно зарегистрировать как приложение (client) на стороне провайдера. В Keycloak это делается в разделе Clients → Create, в AD FS — через мастер добавления Application Group, у других провайдеров логика аналогична. В результате регистрации вы получаете два ключевых параметра: Client ID и Client Secret — их 1С будет предъявлять при обращении за токеном.

При регистрации обязательно укажите redirect URI — адрес, на который провайдер вернёт пользователя после успешного входа. Для 1С это URL опубликованной базы с техническим суффиксом обработчика аутентификации (точный вид зависит от версии платформы и указывается в документации к вашему релизу; как правило, это адрес публикации с путём обработчика OpenID Connect). Ошибка в этом адресе — самая частая причина сообщения «redirect_uri mismatch».

Также на стороне провайдера настройте тип потока (flow). Для 1С используется Authorization Code Flow — самый безопасный вариант, при котором код авторизации обменивается на токен серверным вызовом. Не включайте Implicit Flow, если этого не требует конкретная версия платформы: он считается менее защищённым.

Настройка публикации и файла default.vrd

Основная настройка на стороне 1С выполняется в диалоге публикации на веб-сервере. В конфигураторе откройте «Администрирование → Публикация на веб-сервере» и на закладке настроек аутентификации укажите использование OpenID Connect. Платформа запишет соответствующие параметры в файл default.vrd каталога публикации.

В файле default.vrd за аутентификацию отвечает элемент, содержащий ссылку на провайдера: адрес метаданных (discovery URL), Client ID и Client Secret, а также имя claim, по которому будет сопоставляться пользователь. При необходимости файл можно редактировать вручную текстовым редактором, но делать это следует аккуратно: ошибка в XML полностью сломает публикацию.

После изменения default.vrd перезапустите веб-сервер (для Apache — перезапуск службы, для IIS — перезапуск пула приложений или самого сайта), иначе настройки не применятся. Проверьте, что публикация по-прежнему открывается в браузере: теперь вместо стандартного диалога ввода логина и пароля должен происходить перенаправление на страницу входа провайдера.

1. 1
   Убедитесь, что платформа версии 8.3.17 или новее и база опубликована на веб-сервере
2. 2
   Зарегистрируйте приложение у OIDC-провайдера, получите Client ID и Client Secret, укажите redirect URI базы
3. 3
   В конфигураторе откройте «Администрирование → Публикация на веб-сервере» и включите аутентификацию OpenID Connect, указав параметры провайдера
4. 4
   Проверьте или отредактируйте default.vrd: URL метаданных провайдера, Client ID, Client Secret, claim сопоставления
5. 5
   Перезапустите веб-сервер и откройте базу в браузере — должно произойти перенаправление на страницу входа провайдера
6. 6
   Войдите тестовой учётной записью и убедитесь, что в 1С открылся сеанс нужного пользователя

Сопоставление пользователей провайдера и информационной базы

Сам факт успешного входа у провайдера ещё не означает входа в 1С: платформа должна понять, какому пользователю информационной базы соответствует пришедший токен. Для этого в свойствах пользователя 1С (в конфигураторе или через «Администрирование → Пользователи» в режиме предприятия) заполняется поле, связанное с OpenID Connect, — туда записывается значение идентификатора из токена.

По умолчанию сопоставление обычно выполняется по claim sub — уникальному идентификатору субъекта у провайдера. В зависимости от провайдера и настроек можно использовать другой claim, например email или preferred_username, но помните: sub гарантированно неизменен, а email пользователь теоретически может сменить, и тогда привязку придётся перенастраивать.

Узнать фактическое значение claim для конкретного человека можно в административной консоли провайдера (просмотр атрибутов пользователя) либо выполнив тестовый вход и посмотрев содержимое выданного токена. Удобная практика — сначала настроить одного тестового пользователя, добиться его успешного входа и только потом массово заполнять привязки остальным, например обработкой.

Не отключайте сразу парольную аутентификацию для всех. Оставьте хотя бы одному администратору вход по паролю ОС или 1С: если провайдер окажется недоступен (сбой, истёкший сертификат), вы сохраните возможность зайти в базу и исправить настройки.

Проверка результата и диагностика неполадок

Признак корректной настройки: при открытии URL базы браузер перенаправляется на страницу входа провайдера, после ввода учётных данных возвращается в 1С, и открывается сеанс именно того пользователя, который привязан к этой учётной записи. В журнале регистрации при этом фиксируются события аутентификации.

Если вход не работает, диагностику ведите по цепочке. Сначала смотрите, на каком шаге обрыв: не открывается страница провайдера (проблема сети или сертификатов), провайдер сообщает об ошибке redirect_uri (несовпадение адреса возврата), либо провайдер пропускает, а 1С выдаёт ошибку аутентификации (не заполнена привязка пользователя, неверный Client Secret, недоверенная подпись токена). Журнал регистрации 1С и логи провайдера вместе почти всегда показывают точное место сбоя.

Контрольные точки

Как проверить результат

Открытие URL базы

Норма

Перенаправление на страницу входа провайдера

Тревожный признак

Обычный диалог логина/пароля 1С — OIDC не включился, проверьте default.vrd и перезапуск веб-сервера

Возврат после входа

Норма

Браузер возвращается в 1С без ошибок

Тревожный признак

Ошибка redirect_uri mismatch — поправьте адрес возврата у провайдера

Сеанс в 1С

Норма

Открыт сеанс привязанного пользователя, в журнале регистрации успешная аутентификация

Тревожный признак

Сообщение о невозможности аутентификации — проверьте claim-привязку и Client Secret

Повторный вход

Норма

Вход работает стабильно, в том числе после перезапуска браузера

Тревожный признак

Периодические сбои — проверьте сроки жизни токенов и сертификаты

Типичные ошибки и ограничения механизма

Наиболее частые ошибки сводятся к нескольким пунктам: опечатка в redirect URI, истёкший или неверно скопированный Client Secret, недоверенный сертификат провайдера на сервере 1С и незаполненная привязка пользователя. Отдельная группа проблем — расхождение часов между сервером 1С и провайдером: токены проверяются по времени жизни, и заметный сдвиг часов приводит к отказам. Настройте синхронизацию времени по NTP на всех участвующих серверах.

Из ограничений стоит помнить: механизм работает только через веб-доступ, требует платформы не ниже 8.3.17 и зависит от доступности провайдера — при его отказе вход через OIDC невозможен. Также не все провайдеры одинаково совместимы: перед внедрением в продуктив проверьте конкретную связку на тестовой базе.

Частые вопросы

Можно ли включить OpenID Connect для файловой базы без веб-сервера?

Нет. Механизм работает только при доступе к базе через веб-сервер (Apache или IIS), потому что перенаправления и обмен токенами выполняются по HTTP. Файловую базу нужно сначала опубликовать.

Нужно ли дорабатывать конфигурацию для работы OIDC?

Обычно нет: настройка выполняется средствами платформы — публикацией и файлом default.vrd, плюс заполнением привязки в карточках пользователей. Доработка может понадобиться только для нестандартных сценариев, например автоматического создания пользователей при первом входе.

Что произойдёт, если провайдер OpenID Connect станет недоступен?

Пользователи, у которых включён только вход через OIDC, войти не смогут. Поэтому рекомендуется оставить администраторам альтернативный способ аутентификации (пароль 1С или ОС) и иметь план аварийного отключения OIDC через правку default.vrd.

Можно ли использовать одновременно OIDC и обычный пароль 1С?

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

По какому полю лучше привязывать пользователя — email или sub?

Надёжнее sub: это неизменный идентификатор у провайдера. Email и логин могут меняться, и тогда привязку придётся обновлять вручную. Email разумен лишь как временный вариант при массовом первоначальном заполнении.

Работает ли OpenID Connect в тонком клиенте?

Да, если подключение идёт через веб-сервер (по HTTP/HTTPS к опубликованной базе). При прямом подключении к серверу 1С по протоколу tcp механизм OIDC не применяется.