Как настроить авторизацию OpenID Connect в API Диадок для 1С?

При интеграции собственных решений с API Диадок (удобнее через модуль прямого обмена с Диадок без промежуточных файлов) разработчики часто сталкиваются с переходом на современные методы аутентификации. Поскольку Контур планомерно переводит пользователей с классической авторизации (логин/пароль или сертификат) на стандарт OpenID Connect (OIDC), важно понимать, как правильно организовать этот процесс, особенно в фоновых задачах. Давайте разберем по шагам, как реализовать этот механизм, так как официальная документация может содержать неочевидные нюансы.

Основные принципы авторизации OIDC в Диадоке

Первое, что нужно уяснить: Диадок не поддерживает Client Credentials Flow для полностью фоновой работы без участия пользователя. Это значит, что для получения начального доступа обязательно требуется пользовательский контекст. Для решения этой задачи используется Device Authorization Grant (поток авторизации устройства).

Главная техническая сложность заключается в том, что параметры запроса к серверу identity.kontur.ru должны передаваться не через параметры строки запроса, а в теле HTTP-запроса с заголовком Content-Type: application/x-www-form-urlencoded. При этом данные передаются как простая строка, а не JSON.

Реализация запроса к серверу авторизации

Рассмотрим структуру функции, которая выполняет запросы к серверу идентификации — для этого пригодится универсальная консоль запросов и отладки кода 1С. Для работы нам понадобятся методы deviceauthorization для инициации процесса и token для получения или обновления токенов.

Функция ДиадокАПИ_ВыполнитьЗапросАвторизацииOIDC(АвторизацияЭДО, ИмяМетода, ДополнительныйПараметр = Неопределено, ОбновитьТокены = Ложь) Экспорт
    ЗащищенноеСоединениеOpenSSL = Новый ЗащищенноеСоединениеOpenSSL(
        Новый СертификатКлиентаWindows(),
        Новый СертификатыУдостоверяющихЦентровWindows());
    Соединение = Новый HTTPСоединение("identity.kontur.ru",,,,,,ЗащищенноеСоединениеOpenSSL);
    
    ЗаголовкиЗапроса = Новый Соответствие;
    ЗаголовкиЗапроса.Вставить("Content-Type", "application/x-www-form-urlencoded");

    client_id = КодироватьСтроку(АвторизацияЭДО.ИдентификаторКлиентаOpenID, СпособКодированияСтроки.КодировкаURL);
    client_secret = КодироватьСтроку(АвторизацияЭДО.СекретныйКлючOpenID, СпособКодированияСтроки.КодировкаURL);
    
    // Формируем параметры в зависимости от метода
    Если ИмяМетода = "deviceauthorization" Тогда
        scope = КодироватьСтроку("openid offline_access profile email Diadoc.PublicAPI", СпособКодированияСтроки.КодировкаURL);
        ПараметрыЗапроса = СтрШаблон("client_id=%1&client_secret=%2&scope=%3", client_id, client_secret, scope);
    ИначеЕсли ИмяМетода = "token" Тогда
        // Логика обновления токенов или первичного получения
    КонецЕсли;
    
    HTTPЗапрос = Новый HTTPЗапрос("/connect/" + ИмяМетода, ЗаголовкиЗапроса);
    HTTPЗапрос.УстановитьТелоИзСтроки(ПараметрыЗапроса);
    Ответ = Соединение.ОтправитьДляОбработки(HTTPЗапрос);
    // Обработка ответа...
КонецФункции

Пошаговый сценарий авторизации пользователя

Весь процесс работы с токенами можно разделить на несколько этапов:

1. Инициация авторизации: Мы вызываем метод deviceauthorization. В ответ получаем код устройства device_code и ссылку verification_uri_complete.
2. Подтверждение пользователем: Программно открываем полученную ссылку в браузере (используя ЗапуститьПриложение). Пользователь входит в свой аккаунт Диадока и подтверждает доступ.
3. Получение токенов: После подтверждения вызываем метод token, передав в него полученный device_code. На выходе получаем access_token и refresh_token.
4. Поддержание сессии: Так как access_token живет ограниченное время (обычно сутки), необходимо настроить автоматическое обновление через refresh_token.

Пример кода для клиентской части 1С

Для удобства работы пользователей создадим команды, которые позволят управлять жизненным циклом токенов прямо из интерфейса 1С.

// Команда запуска авторизации в браузере
&НаКлиенте
Процедура КомандаАвторизация(Команда)
    АдресАвторизации = ПолучитьАдресАвторизации(); // Вызывает серверную функцию
    Если АдресАвторизации <> Неопределено Тогда
        ЗапуститьПриложение(АдресАвторизации + "&prompt=login");
    КонецЕсли;
КонецПроцедуры

// Команда получения первичных токенов
&НаКлиенте
Процедура КомандаЗаполнитьТокены(Команда)
    КомандаЗаполнитьТокеныНаСервере(Ложь);
КонецПроцедуры

// Команда обновления токенов (для регламентных заданий)
&НаКлиенте
Процедура КомандаОбновитьТокены(Команда)
    КомандаЗаполнитьТокеныНаСервере(Истина);
КонецПроцедуры

Рекомендации по автоматизации и стабильности

Чтобы ваша интеграция работала надежно и не требовала ручного вмешательства каждое утро, обратите внимание на следующие моменты:

• Автообновление: В регламентном задании, которое выполняет обмен с Диадоком (для этого есть готовый фоновый обмен и электронный архив Диадок), всегда проверяйте актуальность access_token. Если при запросе к API вы получаете ошибку 401 Unauthorized, это прямой сигнал для вызова процедуры обновления токенов через refresh_token.
• Жизненный цикл токенов: Проведенные тесты показывают, что refresh_token остается рабочим даже после истечения срока жизни access_token. Это позволяет организовать стабильный обмен в автоматическом режиме.
• Логирование: Обязательно логируйте все ошибки авторизации (в этом поможет модуль логирования HTTP-запросов и анализа ошибок API). Поскольку OpenID Connect — это многошаговый процесс, наличие подробных логов поможет быстро понять, на каком этапе (запрос кода или обмен токена) произошел сбой.
• Безопасность: Храните токены в защищенном месте (например, в справочнике с ограниченными правами доступа или зашифрованными значениями), чтобы предотвратить их компрометацию.

Использование описанного подхода позволит вам успешно перейти на современные стандарты безопасности Контура и обеспечить бесперебойную работу вашего обмена документами в автоматизированном режиме.