← На главную

Авторизация в информационных системах играет ключевую роль в обеспечении безопасности и конфиденциальности данных. В контексте 1С и её HTTP-сервисов, стандартная базовая авторизация по логину и паролю пользователя 1С часто оказывается недостаточной или неоптимальной, особенно когда требуется интеграция с внешними системами, использующими токены. Рассмотрим различные подходы к реализации авторизации в 1С по токену, начиная с обходных путей, предложенных на форумах, и заканчивая современными, стандартизированными решениями, доступными в платформе.

Наша цель — разобраться, как можно перейти от традиционной авторизации к более гибким и безопасным методам на основе токенов, таким как JWT или OAuth 2.0/OpenID Connect. Мы проанализируем преимущества и недостатки каждого подхода, а также рассмотрим особенности их реализации в экосистеме 1С.

Традиционные подходы и "прокладки"

На ранних этапах развития веб-интеграций в 1С, когда встроенных механизмов работы с токенами не было, разработчики часто прибегали к различным "обходным" решениям. Эти методы, хоть и требовали дополнительных усилий и инфраструктуры, позволяли решить задачу авторизации по токену.

1. Использование прокси-сервера ("умная прокладка")

Одним из наиболее распространенных способов было создание промежуточного звена — прокси-сервера, который брал на себя функцию преобразования внешнего токена в авторизационные данные, понятные 1С. Этот подход часто называют "умной прокладкой".

Принцип работы:

1. Внешняя система или клиент отправляет HTTP-запрос к HTTP-сервису 1С, содержащий токен в заголовках или теле запроса.
2. Этот запрос сначала попадает на прокси-сервер (например, на базе Nginx или IIS ARR), который расположен перед веб-сервером 1С.
3. Прокси-сервер перехватывает запрос.
4. На прокси-сервере реализуется логика, которая:
   • Извлекает внешний токен из запроса.
   • Проверяет подлинность и срок действия этого токена (возможно, обращаясь к внешнему сервису или внутреннему хранилищу).
   • На основании данных из токена или результатов его проверки, прокси-сервер находит соответствующие учетные данные пользователя 1С (логин и пароль).
   • Прокси-сервер формирует новый HTTP-запрос к 1С, заменяя внешний токен на стандартный заголовок Authorization: Basic [Base64(логин:пароль)]
   • Этот "подмененный" запрос отправляется уже непосредственно к веб-серверу 1С.
5. 1С получает запрос с базовой авторизацией и обрабатывает его как обычно.

Сценарии использования:

• Авторизация внешних дилеров, партнеров или клиентов, которые не имеют прямых учетных записей в 1С, но используют свои токены для доступа к API.
• Интеграция с корпоративными порталами, где пользователи авторизуются один раз, а далее портал генерирует токены для доступа к различным внутренним сервисам, включая 1С.

Преимущества:

• Минимальные изменения в 1С: Не требуется доработка конфигурации 1С для работы с токенами, если прокси полностью берет на себя логику авторизации.
• Централизованное управление: Всей логикой авторизации по токенам можно управлять на уровне прокси-сервера, что удобно для мониторинга и аудита.
• Гибкость: Позволяет интегрироваться с практически любыми внешними системами, генерирующими токены.

Недостатки:

• Дополнительный слой инфраструктуры: Требует развертывания и настройки отдельного прокси-сервера.
• Безопасность хранения учетных данных: Логины и пароли пользователей 1С должны храниться на прокси-сервере или в его базе данных, что требует особого внимания к их защите.
• Усложнение архитектуры: Добавляет еще один компонент в цепочку запросов, что может усложнить отладку и поддержку.

Для реализации такой "прокладки" часто используют Nginx с модулями, позволяющими писать свою логику (например, Lua-скрипты), или же IIS с модулем URL Rewrite и кастомными обработчиками.

2. Авторизация по цифровой подписи (исторический подход)

В некоторых случаях, особенно в более ранних реализациях, использовался подход, основанный на цифровой подписи. Этот метод подразумевал генерацию уникальной "цифровой подписи" (или ключа), которая хранилась на стороне клиента (например, на флешке) и проверялась веб-сервером при подключении.

Принцип работы:

1. Специальное приложение или устройство генерирует уникальную цифровую подпись.
2. Эта подпись хранится на клиенте (например, на USB-носителе или в защищенном хранилище).
3. При попытке подключения к веб-сервису 1С, клиент передает эту цифровую подпись.
4. На уровне веб-сервера (в файле публикации 1С или с помощью дополнительных модулей) выполняется проверка этой подписи.
5. Если подпись действительна, доступ к HTTP-сервису предоставляется.

Особенности:

• Это достаточно старый и специализированный метод, который требует глубокого понимания криптографии и соответствующей настройки на уровне веб-сервера.
• Его применимость в современных условиях, особенно для типовых HTTP-сервисов и API, ограничена из-за сложности реализации, поддержки и интеграции с другими стандартами.
• Чаще всего такой подход использовался для защиты доступа к самим информационным базам, а не к отдельным HTTP-сервисам, и мог быть реализован через механизмы аутентификации на уровне операционной системы или провайдера веб-сервера.

Современные механизмы авторизации в платформе 1С

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

Важность HTTPS для любой авторизации

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

1. Авторизация по JSON Web Token (JWT)

Начиная с версии платформы 8.3.21, в 1С появилась встроенная поддержка авторизации по JSON Web Token (JWT). Это значительно упрощает реализацию безопасной и стандартизированной авторизации по токену. Для создания и проверки токенов с подписью HS256 пригодится обработка для создания JWT-токенов в 1С.

Что такое JWT?

JWT — это компактный, URL-безопасный стандарт для представления утверждений (claims), которые передаются между двумя сторонами. JWT состоит из трех частей, разделенных точками:

1. Заголовок (Header): Содержит тип токена (JWT) и используемый алгоритм подписи (например, HS256 или RS256).
2. Полезная нагрузка (Payload): Содержит набор утверждений (claims) — информацию о сущности (обычно о пользователе) и дополнительные данные. Стандартные утверждения включают:
   • iss (issuer) — эмитент токена.
   • sub (subject) — субъект токена (например, идентификатор пользователя).
   • aud (audience) — аудитория, для которой предназначен токен.
   • exp (expiration time) — время истечения срока действия токена.
   • iat (issued at) — время выдачи токена.
3. Цифровая подпись (Signature): Создается путем кодирования заголовка и полезной нагрузки в Base64Url, объединения их точкой и применения криптографического алгоритма (указанного в заголовке) с секретным ключом. Подпись гарантирует, что токен не был изменен в процессе передачи и что он был выдан доверенным эмитентом.

Принцип работы в 1С:

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

1. Генерация токена: В 1С (начиная с 8.3.21) мы можем программно создавать объект ТокенДоступа и подписывать его с использованием различных алгоритмов. Этот объект позволяет настроить все необходимые утверждения (claims) и выбрать алгоритм шифрования. Сгенерированный токен представляет собой строку.
2. Передача токена: Сформированный JWT-токен передается в HTTP-запросе к HTTP-сервису 1С. Это может быть сделано одним из способов:
   • В заголовке Authorization в формате Bearer Token: Authorization: Bearer <ваш_jwt_токен>
   • Через параметр запроса AccessToken: GET /e1cib/hs/MyService?AccessToken=<ваш_jwt_токен>
3. Проверка токена в 1С: Платформа 1С автоматически перехватывает запросы с JWT. Она проверяет:
   • Целостность подписи токена с использованием настроенных ключей.
   • Срок действия токена (поле exp).
   • Доверенного эмитента (поле iss).
   • Сопоставляет данные токена (например, поле sub или email) с существующими пользователями 1С согласно настройкам.
4. Авторизация пользователя: Если все проверки пройдены успешно, 1С авторизует пользователя, соответствующего данным токена, и запрос обрабатывается от его имени.

Настройка публикации (.vrd):

Для активации и настройки JWT-авторизации необходимо внести изменения в файл веб-публикации 1С (.vrd) для вашей информационной базы или конкретного HTTP-сервиса. Мы указываем, каким эмитентам доверяем, какими ключами проверять подпись и как сопоставлять данные из токена с пользователями 1С:

1. AccessTokenIssuers: Список доверенных эмитентов токенов. Мы указываем URL-адреса или идентификаторы систем, которые могут генерировать токены, принимаемые этой 1С.
2. JwtKeys: Секции для хранения открытых ключей (public keys), используемых для проверки цифровой подписи JWT-токенов. Мы можем использовать ключи в форматах PEM, JWKS (JSON Web Key Set) или просто Base64-кодированные секреты для HMAC.
3. AccessTokenClaimsUserMapping: Правила сопоставления полей из полезной нагрузки токена (claims) с пользователями 1С. Например, мы можем указать, что поле sub (subject) из токена должно соответствовать имени пользователя 1С, или поле email — адресу электронной почты пользователя.
4. AuthenticationByAccessTokenAllowed: Для каждого пользователя 1С можно явно разрешить или запретить аутентификацию по токенам через его свойства или программно.

Применение:

JWT-авторизация идеально подходит для:

• Бесшовной кроссплатформенной интеграции между конфигурациями 1С: Например, когда пользователь авторизован в 1С:ERP, он может получать доступ к HTTP-сервисам 1С:Документооборот без повторной авторизации, используя токен, выданный ERP.
• Интеграции с внешними микросервисными архитектурами: Где JWT является стандартом для аутентификации и авторизации между сервисами.
• API-доступа: Предоставление защищенного доступа к API 1С для мобильных приложений или сторонних веб-сервисов.

2. Авторизация по протоколам OAuth 2.0 и OpenID Connect (OIDC)

1С также поддерживает интеграцию с системами, использующими более широкие протоколы авторизации и аутентификации — OAuth 2.0 и OpenID Connect (OIDC). Эти протоколы позволяют реализовать единый вход (Single Sign-On, SSO) и использовать учетные записи внешних OIDC-совместимых сервисов (Google, Microsoft, Yandex Identity Hub, Keycloak) для входа в 1С. Для практической реализации такой авторизации подойдёт готовое решение для аутентификации через Google OAuth 2.0.

Различия между OAuth 2.0 и OIDC:

• OAuth 2.0: Это протокол авторизации. Он предназначен для делегирования доступа — пользователь предоставляет приложению разрешение на доступ к своим данным или ресурсам на другом сервере, не передавая при этом свои учетные данные приложению.
• OpenID Connect (OIDC): Это слой аутентификации поверх OAuth 2.0. Он позволяет клиентам верифицировать личность конечного пользователя на основе аутентификации, выполненной авторизационным сервером, а также получать базовую информацию профиля конечного пользователя.

Преимущества использования OIDC:

• Единый вход (SSO): Пользователи могут входить в 1С, используя уже существующие учетные записи внешних сервисов, что значительно упрощает процесс входа и улучшает пользовательский опыт.
• Повышенная безопасность: Аутентификация централизована и выполняется доверенным OIDC-провайдером, снижая риски, связанные с хранением паролей в множестве систем.
• Снижение нагрузки на пользователя: Не нужно запоминать множество логинов и паролей для разных систем.

Реализация интеграции с OIDC в 1С:

1С может выступать в роли OIDC-клиента. Процесс интеграции включает следующие шаги:

1. Регистрация приложения в OIDC-провайдере: Мы регистрируем нашу 1С-систему как клиентское приложение у выбранного OIDC-провайдера (например, Google Cloud Console, Azure AD). В результате получаем Client ID (идентификатор клиента) и Client Secret (секретный ключ клиента).
2. Настройка 1С для работы с OIDC: В конфигурации 1С требуется доработка для вызова внешних OIDC-провайдеров. Это включает:
   • Формирование URL для перенаправления пользователя на страницу аутентификации OIDC-провайдера.
   • Обработка обратного вызова (callback) от OIDC-провайдера, который содержит Authorization Code.
3. Обмен Authorization Code на токены: После получения Authorization Code, 1С отправляет запрос к OIDC-провайдеру (используя Client ID и Client Secret) для обмена этого кода на Access Token (для доступа к ресурсам) и ID Token (для информации о пользователе).
4. Проверка и разбор ID Token: ID Token — это JWT-токен, который содержит информацию о прошедшем аутентификацию пользователе. 1С проверяет его подпись и срок действия, а затем извлекает из него информацию (например, email, имя пользователя), которую сопоставляет с учетными записями 1С.
5. Авторизация пользователя в 1С: На основе полученной и проверенной информации, 1С либо создает нового пользователя (если его нет), либо авторизует существующего.

Платформа 1С предоставляет необходимые инструменты для выполнения HTTP-запросов и работы с JSON, что делает реализацию OIDC-клиента вполне выполнимой на встроенном языке. Более того, продукты, такие как "1С:Шина", уже предлагают встроенные механизмы для упрощенной настройки аутентификации OAuth2 для входа пользователей в приложения, что значительно облегчает процесс.

Дополнительная информация и рекомендации

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

Сервер-серверная авторизация OAuth 2.0 (Two-legged OAuth)

В некоторых сценариях требуется авторизация между двумя системами без участия конечного пользователя. Это называется "двухсторонняя" или "сервер-серверная" авторизация OAuth 2.0 (иногда её называют Client Credentials Grant Type или использованием Service Accounts). В этом случае 1С может выступать в роли клиента, который авторизуется в API внешних сервисов (например, Google API) напрямую, используя свои учетные данные (Client ID, Client Secret) или цифровую подпись, без необходимости подтверждения от пользователя.

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

Внешние Identity-провайдеры

Для реализации более сложных сценариев единого входа (SSO), централизованного управления пользователями и гибкой политики безопасности, мы можем интегрировать 1С с внешними Identity-провайдерами (IdP). Такие решения, как IdentityServer 4, Azure B2C или Keycloak, предоставляют полноценную инфраструктуру для OIDC и OAuth 2.0. В этом случае 1С будет выступать как клиент для этих IdP, делегируя им функции аутентификации и получения информации о пользователе.

Преимущества: Полный контроль над аутентификацией, поддержка множества протоколов, широкие возможности по настройке политик безопасности, интеграция с каталогами пользователей (LDAP, Active Directory).

Заключение

Мы рассмотрели различные подходы к реализации авторизации по токену в 1С HTTP-сервисах: от "умных прокладок" и прокси-серверов до современных механизмов, встроенных в платформу. Если раньше приходилось изобретать собственные решения или использовать прокси для преобразования токенов во внутреннюю авторизацию 1С, то сегодня, с появлением поддержки JWT (начиная с версии 8.3.21) и возможностями интеграции с OIDC-провайдерами, платформа 1С предоставляет стандартизированные и безопасные инструменты.

При выборе метода авторизации, мы рекомендуем отдавать предпочтение встроенным возможностям платформы 1С для работы с JWT и интеграции с OIDC. Эти подходы обеспечивают высокую безопасность, гибкость и соответствие современным стандартам. Использование прокси-серверов оправдано в случаях, когда требуется поддержка устаревших систем, или когда невозможно обновить платформу 1С до требуемой версии. Независимо от выбранного метода, мы должны помнить о фундаментальной важности использования HTTPS для защиты передаваемых данных.