Администрирование · 12 мин
Аутентификация по протоколу OpenID в 1С: что это и как настроить
Что такое аутентификация OpenID в 1С, как она работает, чем отличается от OpenID Connect и OAuth, как настроить вход пользователей и какие ошибки встречаются чаще всего.
Аутентификация по протоколу OpenID в 1С — это способ входа пользователей в информационную базу, при котором проверку логина и пароля выполняет не сама база, а внешний сервер аутентификации. Платформа 1С:Предприятие поддерживает этот механизм на уровне настроек пользователя: в свойствах учётной записи можно включить «Аутентификация OpenID», и тогда при подключении клиент будет перенаправлен на указанный сервер для подтверждения личности.
Такая схема нужна там, где несколько баз или веб-приложений должны принимать одни и те же учётные данные. Вместо того чтобы хранить пароли в каждой базе и заставлять сотрудников запоминать несколько комбинаций, администратор поднимает единый сервер аутентификации, а все прикладные решения доверяют его решению о том, кто перед ними.
Важно сразу разграничить понятия: классический OpenID (версии 1.x и 2.0) и современный OpenID Connect, построенный поверх OAuth 2.0, — разные протоколы. Платформа 1С исторически поддерживает именно OpenID, а интеграции с корпоративными провайдерами вроде Keycloak или Active Directory Federation Services чаще строятся через OpenID Connect или через веб-сервисы с токенами. Путаница между ними — частая причина неудачных настроек.
Что такое OpenID и как он работает в связке с 1С
OpenID — открытый протокол децентрализованной аутентификации. Его базовая идея: пользователь доказывает свою личность одному серверу (провайдеру идентификации), а все остальные системы, которым он нужен, доверяют этому серверу. Пароль при этом не передаётся в прикладную систему — она получает только подтверждение, что аутентификация прошла успешно, и идентификатор пользователя.
В контексте 1С схема выглядит так. Пользователь запускает клиент и указывает базу. Платформа видит, что для его учётной записи включена OpenID-аутентификация, и вместо стандартного окна «логин/пароль» перенаправляет запрос на сервер аутентификации. Тот запрашивает учётные данные, проверяет их и возвращает подписанное подтверждение. Если проверка пройдена и идентификатор совпадает с тем, что указан в карточке пользователя, сеанс открывается.
Практическая особенность платформы: в экосистеме 1С сервером аутентификации может выступать отдельная информационная база, специально подготовленная для этой роли. Это удобно, когда нужно объединить вход в несколько баз одной организации без внедрения сторонних решений.
Когда OpenID в 1С оправдан, а когда лучше другой способ
Единый вход имеет смысл, когда у организации несколько информационных баз — например, учётная, зарплатная и отдельная база для веб-портала — и одни и те же сотрудники работают во всех. Без централизованной аутентификации администратор вынужден заводить пользователей в каждой базе, а при увольнении сотрудника — помнить обо всех местах, где нужно закрыть доступ.
Для небольшой базы с десятком пользователей OpenID чаще избыточен: проще встроенная аутентификация 1С или аутентификация операционной системы (доменная). Последняя вообще не требует ввода пароля, если компьютер в домене, и покрывает большинство сценариев локальной сети.
Сравнение способов входа в 1С
Логин и пароль хранятся в самой базе. Подходит для одной базы, проста в настройке, но не масштабируется на несколько систем.
Вход под учётной записью Windows без ввода пароля. Удобна в доменной сети, но не работает для внешних пользователей и веб-доступа извне.
Единый вход в несколько баз и веб-приложений через общий сервер. Требует развёртывания и поддержки сервера аутентификации.
Современный вариант для интеграции с корпоративными провайдерами и облачными сервисами. В 1С обычно реализуется прикладной разработкой, а не штатной настройкой.
Если задача — связать 1С с корпоративным провайдером удостоверений (Keycloak, ADFS, Azure AD), штатной OpenID-настройки недостаточно: потребуется прикладная доработка — HTTP-сервисы, обмен токенами, обработка JWT. Это уже задача разработки, а не администрирования.
Что нужно подготовить перед настройкой
Прежде чем включать OpenID в карточках пользователей, убедитесь, что выполнены базовые условия. Игнорирование любого из них приводит к тому, что вход просто не работает, и диагностика занимает часы.
- 1Разверните сервер аутентификации: отдельную базу 1С или внешний OpenID-провайдер, доступный по сети для всех клиентов.
- 2Проверьте, что адрес сервера аутентификации доступен с клиентских машин — откройте его в браузере с типового рабочего места.
- 3Составьте соответствие идентификаторов: какой OpenID-идентификатор будет у каждого пользователя базы.
- 4Настройте публикацию на веб-сервере, если клиенты подключаются через веб или сервер аутентификации работает по HTTP/HTTPS.
- 5Включите OpenID-аутентификацию в свойствах пользователя и укажите его идентификатор.
- 6Проверьте вход под тестовой учётной записью до массового включения настройки.
Отдельное внимание — сертификатам. Если сервер аутентификации работает по HTTPS с самоподписанным сертификатом, клиентские машины должны ему доверять, иначе соединение будет рваться с ошибкой, которую легко принять за неверный пароль. В тестовом контуре можно использовать HTTP, в продуктивном — только HTTPS.
Настройка OpenID-аутентификации для пользователя
На стороне прикладной базы настройка выполняется в конфигураторе. Откройте список пользователей (Администрирование → Пользователи), выберите учётную запись и в её свойствах отметьте вариант «Аутентификация OpenID». В поле идентификатора укажите строку, по которой сервер аутентификации опознает этого пользователя — обычно это URL или URN, выданный провайдером.
Обратите внимание: виды аутентификации в 1С можно комбинировать. Если оставить включённой и обычную аутентификацию (пароль 1С), пользователь сможет входить обоими способами. Это удобно на переходный период, но с точки зрения безопасности ослабляет схему — после стабилизации единого входа локальные пароли лучше отключить.
Настройка через кластер серверов
В клиент-серверном варианте часть параметров задаётся на уровне информационной базы в консоли кластера. Там же контролируются настройки, влияющие на то, какие виды аутентификации разрешены для базы в целом. После изменения параметров кластера проверяйте, не требуется ли перезапуск сеансов: активные соединения могут продолжать работать со старыми настройками.
Публикация и веб-доступ
Если пользователи заходят через веб-клиент или тонкий клиент по HTTP, публикация на веб-сервере (IIS или Apache) должна корректно проксировать запросы аутентификации. Типичная проблема — несовпадение внешнего адреса публикации с адресом, указанным в настройках OpenID: подтверждение приходит на один URL, а клиент ждёт его на другом, и вход завершается ошибкой.
Как проверить, что всё работает
Проверку делайте поэтапно, начиная с сетевой доступности и заканчивая реальным входом. Так проще локализовать сбой: если не открывается страница сервера аутентификации, искать причину в настройках пользователя бессмысленно.
Как проверить результат
Адрес открывается в браузере с клиентской машины без ошибок сертификата
Ошибка соединения, таймаут или предупреждение о недоверенном сертификате
Клиент отправляет на страницу входа провайдера, а не показывает стандартное окно пароля 1С
Обычное окно логина/пароля — значит, OpenID для пользователя не включён
После ввода данных на сервере сеанс в 1С открывается под нужным пользователем
Ошибка сопоставления идентификатора или возврат на страницу входа
В журнале есть событие успешной аутентификации пользователя
Ошибки аутентификации или отсутствие событий вовсе
Журнал регистрации — главный инструмент диагностики. Включите запись событий аутентификации, если она отключена, и смотрите, какой именно этап завершился неудачей: обращение к серверу, проверка подписи ответа или сопоставление идентификатора с пользователем базы.
Типичные ошибки и ограничения
У штатного механизма есть и принципиальные ограничения. Он не решает задачу авторизации — то есть определения прав пользователя. OpenID отвечает только на вопрос «это действительно тот человек?», а роли и права по-прежнему назначаются внутри каждой базы отдельно. Единый вход не означает единые права.
Второе ограничение — зависимость от доступности сервера. Если провайдер идентификации вышел из строя, вход через OpenID невозможен во всех связанных базах одновременно. Для критичных систем продумайте резервирование сервера или аварийный локальный доступ.
OpenID против OpenID Connect и OAuth: что выбрать для интеграций
Если задача выходит за рамки «единый вход между базами 1С» — например, нужно впустить пользователей из корпоративного портала, мобильного приложения или облачного сервиса — ориентируйтесь на OpenID Connect. Это современный стандарт, который поддерживают практически все провайдеры идентификации, и для него есть готовые библиотеки практически под любой стек.
Как выбрать действие
При проектировании интеграции на OAuth 2.0/OpenID Connect в 1С обычно строят такую схему: внешнее приложение получает токен у провайдера, передаёт его в HTTP-сервис 1С, а тот проверяет подпись токена и сопоставляет идентификатор из него с пользователем базы. Это полноценная разработка, требующая понимания формата JWT и работы с криптографией.
Перед внедрением единого входа зафиксируйте процедуру блокировки: при увольнении сотрудника доступ должен закрываться в одном месте — на сервере аутентификации. Именно централизованное отключение доступа, а не удобство входа, чаще всего становится главным аргументом в пользу OpenID.
FAQ
Чем OpenID отличается от OpenID Connect?
Это разные протоколы. Классический OpenID (версии 1.x–2.0) решает только задачу подтверждения личности и считается устаревшим. OpenID Connect — надстройка над OAuth 2.0, которая использует токены формата JWT и поддерживается современными провайдерами. Штатная настройка в 1С относится к классическому OpenID; для OpenID Connect нужна прикладная разработка.
Можно ли использовать OpenID в файловой базе 1С?
Настройка вида аутентификации в карточке пользователя доступна и в файловом варианте, однако практическая применимость ограничена: сервер аутентификации должен быть доступен всем клиентам, а сценарий единого входа обычно возникает именно в клиент-серверной архитектуре с несколькими базами. Для одиночной файловой базы механизм не даёт преимуществ.
Что будет, если сервер аутентификации недоступен?
Пользователи с OpenID-аутентификацией не смогут войти ни в одну связанную базу. Поэтому рекомендуется оставлять резервную учётную запись администратора с локальной аутентификацией и продумывать резервирование самого сервера аутентификации, если от него зависят критичные процессы.
Передаётся ли пароль пользователя в базу 1С при OpenID-входе?
Нет. В этом суть протокола: пароль вводится только на сервере аутентификации, а прикладная база получает подписанное подтверждение и идентификатор пользователя. Благодаря этому компрометация одной базы не раскрывает пароли сотрудников.
Можно ли сочетать OpenID с доменной аутентификацией?
Да, виды аутентификации в свойствах пользователя комбинируются: можно разрешить и вход через Windows-учётную запись, и OpenID. Платформа примет любой успешный способ. На практике такую комбинацию используют на переходный период миграции, затем лишние способы отключают для сокращения поверхности атаки.
Как диагностировать ошибку «пользователь не найден» при OpenID-входе?
Чаще всего причина в несовпадении идентификатора: строка, которую возвращает сервер аутентификации, должна символ в символ совпадать с идентификатором в карточке пользователя. Проверьте регистр, наличие слэша в конце URL и префикс протокола. Точное значение, которое прислал сервер, видно в журнале регистрации при включённой записи событий аутентификации.