Как настроить аутентификацию через JWT для SOAP веб-сервисов (WSПрокси) в 1С?

При работе с HTTP-сервисами в 1С использование JWT (JSON Web Token) является стандартной практикой: мы просто добавляем заголовок Authorization: Bearer [токен] в HTTPЗапрос. Однако при работе с классическими веб-сервисами (SOAP) через объект WSПрокси разработчики часто сталкиваются с ограничением: стандартный объект платформы поддерживает только Basic-аутентификацию (логин/пароль). В этой статье мы разберем, как обойти это ограничение и реализовать нативную поддержку JWT для WSПрокси, используя возможности современных версий платформы 1С:Предприятие 8.3.

Анализ проблемы: почему стандартный подход не работает

Традиционно объект WSПрокси не предоставляет прямого доступа к заголовкам HTTP-пакета. Попытки использовать сторонние советы от ИИ, предлагающие обратиться к несуществующим свойствам вроде WSПрокси.Сессия.HTTPСоединение, не имеют смысла, так как таких свойств в объектной модели 1С нет. Важно понимать: платформа берет на себя управление соединением, и вставить произвольный заголовок в стандартный вызов метода прокси невозможно.

Тем не менее, начиная с версии 8.3.21, 1С реализовала механизм передачи токена доступа через параметры URL. Это позволяет использовать JWT даже там, где нельзя явно задать заголовки.

Шаг 1. Настройка пользователя и информационной базы

Прежде чем писать код, необходимо подготовить базу-приемник. Проанализируем необходимые настройки:

1. В конфигураторе или в режиме "Предприятие" откройте карточку пользователя, под которым будет выполняться вход.
2. Установите флаг "Аутентификация токеном доступа". Без этой галочки система будет игнорировать переданный токен, даже если он валиден.
3. Убедитесь, что у пользователя достаточно прав на исполнение конкретного Веб-сервиса.

Шаг 2. Настройка файла публикации (default.vrd)

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

<jwt>
    <issuer name="http://identity-server-url">
        <pubKey>[Здесь_ваш_публичный_ключ_в_формате_base64]</pubKey>
    </issuer>
</jwt>

Если используется внешняя система авторизации, платформа должна знать, как проверять подпись токена. В параметре claimName (по умолчанию sub) указывается поле токена, которое 1С будет сопоставлять с именем пользователя в базе.

Шаг 3. Реализация вызова веб-сервиса на стороне клиента

Теперь разберем основной программный механизм. Вместо того чтобы пытаться добавить заголовок, мы добавим параметр AccessToken непосредственно в URL веб-сервиса. Посмотрим на правильную последовательность действий:

Важный нюанс: Токен необходимо передавать дважды. Первый раз — при создании WSОпределения (чтобы получить WSDL-схему), второй раз — при инициализации WSПрокси (для вызова самих методов).

// 1. Подготавливаем базовый URL и токен
ТокенДоступа = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."; // Ваш JWT в формате Base64URL
БазовыйURL = "https://server.com/base/ws/MyService.1cws";
URLСТокеном = БазовыйURL + "?AccessToken=" + ТокенДоступа;

// 2. Создаем определения. 
// Если WSDL защищен, без токена здесь возникнет ошибка 401.
Попытка
    Определения = Новый WSОпределения(URLСТокеном + "&wsdl");
Исключение
    Сообщить("Ошибка получения WSDL: " + ОписаниеОшибки());
    Возврат;
КонецПопытки;

// 3. Создаем прокси, явно указывая местоположение с токеном в 8-м параметре
Прокси = Новый WSПрокси(
    Определения, 
    "http://www.my-namespace.org", // Пространство имен
    "MyService",                   // Имя сервиса
    "MyServiceSoap",               // Имя точки подключения
    ,                              // Интернет-прокси
    30,                            // Таймаут
    Новый ЗащищенноеСоединениеOpenSSL(), // Защищенное соединение
    URLСТокеном                    // Местоположение (Location)
);

// 4. Выполняем вызов метода
Результат = Прокси.ИмяМетода(Параметр1);

Разбор критических ошибок при внедрении

Проанализируем типичные причины, по которым вызов может вернуть ошибки 400 Bad Request или 401 Unauthorized:

1. Формат Base64URL: Стандартный Base64 может содержать символы +, / и =, которые являются спецсимволами в URL. Плюс превратится в пробел, и сервер не сможет прочитать токен. Обязательно используйте URL-безопасный алфавит (замена + на -, / на _ и удаление символов = в конце).
2. Локальное хранение WSDL: Если токен имеет очень короткое время жизни (TTL), WSОпределения могут не успеть загрузить схему. В высоконагруженных системах рекомендуется сохранить WSDL в локальный файл и создавать определения из него: Новый WSОпределения(ПутьКФайлу). В этом случае токен передается только в WSПрокси.
3. Логирование на веб-сервере: Помните, что параметры Query String (все, что идет после знака вопроса) часто сохраняются в логах IIS или Apache. Чтобы ваш JWT не "утек" через логи, настройте исключение логирования для строк запроса на соответствующей публикации 1С.

Альтернативный вариант: mTLS

Если передача токена через URL кажется вам небезопасной, а Basic-аутентификация запрещена политикой безопасности, рассмотрим вариант с использованием клиентских сертификатов (mTLS). В WSПрокси это реализуется через объект ЗащищенноеСоединениеOpenSSL, куда передается сертификат клиента. Это абсолютно нативный способ, поддерживаемый 1С "из коробки" без манипуляций с URL.

Заключение

Мы выяснили, что нативная поддержка JWT в WSПрокси существует, но она реализована не через заголовки, а через механизм AccessToken в строке запроса. Это решение требует корректной настройки файла default.vrd и использования Base64URL. При правильном подходе это позволяет строить современные и безопасные интеграции на базе SOAP, сохраняя удобство работы с типизированными объектами 1С.