Администрирование · 13 мин
Аутентификация OpenID Connect в 1С: что это и как настроить
Что такое аутентификация OpenID Connect в 1С, как работает протокол, где применяется в платформе и как настроить вход через внешнего провайдера.
OpenID Connect (OIDC) — это открытый протокол аутентификации, построенный поверх OAuth 2.0, который позволяет пользователям входить в информационную базу 1С через учётную запись внешнего провайдера, не храня пароль в самой системе. Вместо ввода логина и пароля 1С пользователь перенаправляется на страницу доверенного провайдера идентификации, подтверждает личность там, а 1С получает криптографически подписанное подтверждение — ID-токен.
Платформа 1С:Предприятие поддерживает OpenID Connect начиная с версии 8.3.22 как один из методов аутентификации пользователей информационной базы. Это позволяет организациям объединить доступ к 1С с корпоративной системой единого входа (SSO), облачными сервисами идентификации или порталом 1С:Предприятие через Интернет.
Для администратора и разработчика важно понимать, что OIDC в 1С — это не замена механизма ролей и прав доступа. Протокол отвечает только за вопрос «кто этот пользователь», а вопрос «что ему разрешено» по-прежнему решается ролями в конфигурации. Ниже разберём устройство протокола, варианты применения, порядок настройки и типичные ошибки.
Как устроен протокол OpenID Connect
OpenID Connect добавляет к OAuth 2.0 стандартизированный слой идентификации. Если OAuth 2.0 решает задачу делегированного доступа к ресурсам («разрешить приложению действовать от имени пользователя»), то OIDC отвечает на вопрос «кто этот пользователь». Результатом успешной аутентификации является ID-токен — JWT (JSON Web Token), подписанный ключом провайдера и содержащий утверждения (claims) о пользователе: идентификатор, имя, адрес электронной почты и другие атрибуты.
Типовой поток авторизации (Authorization Code Flow) выглядит так: клиентское приложение перенаправляет браузер пользователя на endpoint авторизации провайдера; пользователь вводит свои учётные данные у провайдера; провайдер возвращает код авторизации на адрес обратного вызова (redirect URI); приложение обменивает код на ID-токен и access token по защищённому каналу; приложение проверяет подпись токена и извлекает данные пользователя.
Важное следствие такой схемы: информационная база 1С никогда не видит пароль пользователя. Она доверяет подписи провайдера, проверяя токен по открытым ключам, опубликованным провайдером (обычно через JWKS-endpoint в метаданных discovery-документа). Это снижает риск утечки паролей из базы 1С и упрощает соблюдение политик безопасности.
Где в 1С применяется OpenID Connect
В экосистеме 1С OpenID Connect встречается в нескольких сценариях. Во-первых, это аутентификация пользователей информационной базы через внешнего провайдера: платформа позволяет указать для пользователя способ аутентификации «OpenID Connect» и связать его с учётной записью провайдера. Во-вторых, OIDC используется при работе через тонкий и веб-клиент, опубликованные на веб-сервере, когда вход выполняется через корпоративный портал единого входа.
В-третьих, механизмы на базе OpenID Connect применяются в сервисах фирмы «1С» — например, при работе с 1С:Фреш и связанными облачными сценариями, где учётная запись сервиса выступает поставщиком идентификации. Наконец, разработчики могут использовать OIDC-подобные схемы при построении собственных интеграций, когда 1С выступает клиентом внешнего API, защищённого OAuth 2.0.
Чем OIDC отличается от других способов входа в 1С
Платформа 1С поддерживает несколько методов аутентификации, и выбор между ними зависит от инфраструктуры организации. Понимание различий помогает не смешивать задачи, которые решают разные механизмы.
| Способ | Где проверяется пароль | Когда подходит | Ограничения |
|---|---|---|---|
| Аутентификация 1С (пароль ИБ) | В информационной базе | Небольшие внедрения, изолированные базы | Отдельный пароль, нет единого входа |
| Аутентификация ОС (Windows) | Контроллер домена / ОС | Доменная сеть, толстый клиент | Требует домена, ограничена в веб-сценариях |
| OpenID Connect | Внешний провайдер идентификации | SSO, веб-клиент, облачные и гибридные схемы | Нужен настроенный провайдер, зависимость от его доступности |
Ключевое отличие OIDC от аутентификации ОС — независимость от доменной инфраструктуры и пригодность для веб-сценариев: пользователь может входить в опубликованную базу с любого устройства через браузер, подтверждая личность у провайдера. Отличие от пароля ИБ — централизация: блокировка учётной записи у провайдера мгновенно закрывает доступ ко всем подключённым системам, включая 1С.
Сравнение вариантов
Подходит для небольших баз без требований к SSO; минус — отдельный пароль и ручное управление доступом при увольнении.
Удобна в домене для толстого клиента; ограничение — плохо переносится в веб-клиент и на недоменные устройства.
Выбор для единого входа, веб-доступа и облачных сценариев; требует развёрнутого провайдера и настройки публикации.
Что нужно подготовить перед настройкой
До включения OIDC-аутентификации в 1С необходимо обеспечить несколько предпосылок. Первая — работающий провайдер идентификации, поддерживающий OpenID Connect: это может быть корпоративное решение класса Identity Provider (Keycloak, Active Directory Federation Services с соответствующей настройкой и другие) или облачный сервис идентификации. Провайдер должен быть доступен по HTTPS как с сервера 1С, так и с клиентских машин.
Вторая предпосылка — зарегистрированное клиентское приложение на стороне провайдера. При регистрации вы получаете идентификатор клиента (Client ID), секрет клиента (Client Secret) и указываете разрешённые адреса перенаправления (redirect URI), которые должны точно совпадать с адресами публикации 1С. Несовпадение redirect URI — одна из самых частых причин отказа при входе.
Третья предпосылка — публикация информационной базы на веб-сервере (Apache или IIS) с корректно настроенным HTTPS. OIDC-потоки критичны к защищённому соединению: большинство провайдеров откажутся работать с незащищёнными адресами обратного вызова, кроме специальных отладочных исключений.
- 1Разверните или выберите провайдера идентификации с поддержкой OpenID Connect и убедитесь в его доступности по HTTPS.
- 2Зарегистрируйте у провайдера клиентское приложение: получите Client ID и Client Secret, укажите redirect URI публикации 1С.
- 3Опубликуйте информационную базу на веб-сервере с действующим TLS-сертификатом.
- 4Проверьте, что сервер 1С и клиентские машины резолвят и открывают адреса провайдера.
- 5Создайте тестового пользователя для проверки входа, не отключая у администраторов альтернативный способ аутентификации.
Настройка аутентификации пользователя в 1С
После подготовки инфраструктуры настройка сводится к двум зонам: параметрам публикации и настройкам конкретных пользователей. В файле публикации (default.vrd) указываются параметры подключения к провайдеру OpenID Connect — адреса endpoint'ов, идентификатор клиента и другие атрибуты, определяемые документацией платформы для вашей версии. Эти параметры привязывают публикацию к конкретному провайдеру.
Далее в конфигураторе для нужных пользователей включается способ аутентификации OpenID Connect, и учётная запись связывается с идентификатором пользователя у провайдера. Как правило, связь выполняется по уникальному claim из ID-токена — например, по subject (sub) или по адресу электронной почты, в зависимости от настроек и требований провайдера.
После сохранения настроек выполняется проверка: откройте опубликованную базу в браузере, убедитесь, что происходит перенаправление на страницу провайдера, пройдите аутентификацию и подтвердите, что сеанс 1С открылся под ожидаемым пользователем. Если вход не выполняется, смотрите журнал регистрации и логи веб-сервера — они покажут, на каком шаге потока произошёл сбой.
Как проверить результат
При открытии базы браузер уходит на страницу входа провайдера
Сразу ошибка 1С или страница провайдера не открывается — проверяйте доступность endpoint'ов
После ввода учётных данных браузер возвращается в 1С и открывает сеанс
Ошибка redirect_uri mismatch — адрес обратного вызова не совпадает с зарегистрированным у провайдера
Сеанс открыт под нужным пользователем ИБ, права соответствуют его ролям
Вход под другим пользователем или отказ в сопоставлении — проверяйте claim, по которому идёт связь
Безопасность и типичные ошибки
OpenID Connect переносит ответственность за проверку пароля на провайдера, но добавляет собственные точки отказа. Главный риск — зависимость от доступности провайдера: если сервис идентификации недоступен, пользователи не смогут войти в 1С, даже если сама база работает. Поэтому у административных учётных записей всегда должен оставаться резервный способ входа, иначе при сбое провайдера вы потеряете управление базой.
Вторая группа рисков — некорректная обработка сертификатов. Если сервер 1С не доверяет цепочке сертификатов провайдера (например, самоподписанный сертификат не добавлен в хранилище доверенных), обмен кодом на токен завершится ошибкой. В тестовых контурах это решается установкой сертификата в доверенные, в продуктиве — использованием сертификатов от признанных удостоверяющих центров.
Когда OIDC оправдан, а когда лучше выбрать другое
OpenID Connect оправдан, когда в организации уже есть или планируется система единого входа, когда база публикуется для доступа через Интернет, когда требуется централизованное отключение доступа увольняющихся сотрудников и когда политика безопасности запрещает хранение паролей в прикладных системах. В этих сценариях затраты на развёртывание провайдера окупаются снижением рисков и упрощением администрирования.
Если база работает в изолированной локальной сети на десяток пользователей, внедрение OIDC, скорее всего, избыточно: проще ограничиться паролем ИБ или аутентификацией ОС. Промежуточный вариант — использовать OIDC только для внешних пользователей и веб-доступа, оставив внутренним сотрудникам доменную аутентификацию.
Как выбрать действие
Часто задаваемые вопросы
Хранится ли пароль пользователя в информационной базе при OIDC?
Нет. Пароль вводится только на странице провайдера идентификации. 1С получает подписанный ID-токен и проверяет его подпись по открытым ключам провайдера. В базе хранится лишь связь пользователя с идентификатором у провайдера.
Можно ли использовать OpenID Connect в файловой базе без веб-сервера?
Полноценный OIDC-поток ориентирован на веб-сценарии и требует адресов обратного вызова, поэтому практическое применение связано с публикацией базы на веб-сервере. Для локальной файловой базы без публикации обычно используют пароль ИБ или аутентификацию ОС.
Что произойдёт, если провайдер идентификации станет недоступен?
Пользователи, у которых OIDC — единственный способ входа, не смогут открыть базу. Поэтому администраторам рекомендуется оставлять резервный метод аутентификации, а доступность провайдера — включать в мониторинг инфраструктуры.
Заменяет ли OpenID Connect роли и права в конфигурации?
Нет. OIDC отвечает только за идентификацию — подтверждение личности пользователя. Авторизация, то есть определение доступных объектов и операций, выполняется ролями конфигурации и настройками прав, как и при любом другом способе входа.
По какому атрибуту лучше связывать пользователя 1С с учётной записью провайдера?
Надёжнее использовать стабильный неизменяемый идентификатор, например claim sub из ID-токена. Адрес электронной почты или логин могут измениться, и тогда связь придётся настраивать заново.
Нужен ли HTTPS для работы OIDC в 1С?
Да, практически обязательно. Провайдеры идентификации, как правило, требуют защищённых адресов обратного вызова, а передача токенов по открытому каналу недопустима с точки зрения безопасности. Используйте действующий TLS-сертификат, которому доверяют и клиенты, и сервер 1С.
Что важно запомнить
OpenID Connect в 1С — это вход через внешнего провайдера по подписанному ID-токену, без хранения пароля в базе. Настройка требует работающего провайдера, зарегистрированного клиента, HTTPS-публикации и связи пользователей по стабильному идентификатору. Права по-прежнему задаются ролями, а у администраторов всегда должен оставаться резервный способ входа.