Глоссарий HTTP аутентификации: Basic, Bearer, OAuth и другие непонятные слова

14.05.24

Интеграция - WEB-интеграция

Рано или поздно каждый 1С разработчик сталкивается с задачей автоматизации работы со сторонним сервисом посредством RestAPI. Одними из основных (а, как правило - и самыми запутанными) элементами любой пдобной автоматизации являются процессы авторизации и аутентификации. Токены, подписи, шифрование - как не потеряться во всем этом? Поможет данное краткое руководство

Я решил, что правильно будет разделить все приводимые понятия на уровни, чтобы шаг за шагом пройти наиболее часто встречающиеся термины, начав с самых азов. Однако, надо понимать, что здесь не будет разбора совсем базы, вроде видов http-запросов или что такое "заголовок" - только понятия и примеры по теме

 

Уровень 1: Авторизация и аутентификация

Это два действия, с которых начинается любая интеграция.
 

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

Авторизация - это процесс проверки и выдачи прав соответственно вашему аккаунту. Войдя в свой профиль на сайте, вы получаете доступ к некоторому набору действий, которые были определены вам разработчиками и администраторами - но не более того

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

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


Уровень 2: Схемы Http-аутентификации/авторизации

Рассмотрим основные схемы аутентификации с примерами 

Basic
Самый простой способ аутентификации: в заголовки запроса добавляется заголовок Authorization со значением Basic Логин:Пароль, где пара Логин:Пароль кодированы в Base64. Никакого дополнительного преобразования этих данных не требуется

 

Логин  = "bayselonarrend";
Пароль = "14AB22";
Сервер = "exemple.com";
Адрес  = "/api";

Заголовки = Новый Соответствие;

Basic = Логин + ":" + Пароль;
Basic = Base64Строка(ПолучитьДвоичныеДанныеИзСтроки(Basic));

Заголовки.Вставить("Authorization", "Basic " + Basic);

НовыйЗапрос = Новый HTTPЗапрос(Адрес, Заголовки);

SSL         = Новый ЗащищенноеСоединениеOpenSSL;
Соединение  = Новый HTTPСоединение(Сервер, 443, , , , 3000, SSL);
Ответ       = Соединение.ВызватьHTTPМетод("GET", НовыйЗапрос);

 

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

 




Digest

Более сложная система. Сервер по запросу отправляет клиенту некоторые данные (nonce), после чего клиент преобразует пару логин-пароль в MD5 хэш-строку на их основе. Практически не используется, так как требует хранения пароля в открытом виде на стороне сервера. Как способ аутентификации конкретно для API встречается еще реже, вероятно из-за необходимости отправки предварительного запроса получения nonce, что в обычной жизни берет на себя браузер
 

Про 1С:
MD5 в 1С реализуется штатными средствами через Новый ХешированиеДанных(ХэшФункция.MD5). Также реализация Digest есть в Коннекторе

 


 


Bearer 

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

 

Authorization: Bearer 17fa874c-cdbf-49e5-88fc-625aa63b3b00



Например, вы регистрируетесь на портале ресурса, который предоставляет публичный API. После входа в некоторый "личный кабинет" при помощи логина и пароля, вам становится доступна функция генерации токена. Вы нажимаете на кнопку, копируете себе сгенерированную строку, после чего передаете её в каждом своем запросе к API. Эта строка - Bearer токен

 

Про 1С:

В зависимости от реализации API, Bearer можете передаваться в

  • Заголовках запроса
    Сервер = "exemple.com";
    Адрес  = "/api";
    Токен  = "17fa874c-cdbf-49e5-88fc-625aa63b3b00";
    
    Заголовки = Новый Соответствие;
    Заголовки.Вставить("Authorization", "Bearer " + Токен);
    
    НовыйЗапрос = Новый HTTPЗапрос(Адрес, Заголовки);
    
    SSL         = Новый ЗащищенноеСоединениеOpenSSL;
    Соединение  = Новый HTTPСоединение(Сервер, 443, , , , 3000, SSL);
    Ответ       = Соединение.ВызватьHTTPМетод("GET", НовыйЗапрос);
  • В URL - как, например, у Telegram
    https://api.telegram.org/bot61111111:AAFyzNBOAFfuhAL5GXqbVidwAAAAAAAA/getUpdates
                               |                                         |
                               -------------------------------------------
                                              Вот эта часть
  • В теле запроса
    Сервер = "exemple.com";
    Адрес  = "/api";
    Токен  = "17fa874c-cdbf-49e5-88fc-625aa63b3b00";
    
    Параметры = "?my_token_field=" + Токен;
    
    Заголовки = Новый Соответствие;
    Заголовки.Вставить("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");
    
    НовыйЗапрос = Новый HTTPЗапрос(Адрес, Заголовки);
    НовыйЗапрос.УстановитьТелоИзСтроки(Параметры);
    
    SSL         = Новый ЗащищенноеСоединениеOpenSSL;
    Соединение  = Новый HTTPСоединение(Сервер, 443, , , , 3000, SSL);
    Ответ       = Соединение.ВызватьHTTPМетод("POST", НовыйЗапрос);

     

 


 


AWS4-HMAC-SHA256

Замороченный способ авторизации AWS и всех сочувствующих - поставщиков S3 в частности. Сводится к генерации авторизационных данных на основе не только лишь токена от провайдера, как в Bearer, но и на основе самого содержимого отправляемого запроса. Сформированные данные отправляются в заголовке Authorization
 

Authorization: AWS4-HMAC-SHA256                                             
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, 
SignedHeaders=host;range;x-amz-date,
Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

Где:
 - Строка1 - Наименование метода
 - Строка2 - Строка <Ваш ID ключа доступа>/<Дата>/<Регион AWS>/<Сервис>/aws4_request
 - Строка3 - Список передаваемых заголовков
 - Строка4 - Сигнатура, вычисляемая по одному из доступных алгоритмов

 

Вычисление сигнатуры - вообще отдельная тема. Пока могу предложить только ссылки на ресурсы Amazon:

Для 1С:

AWS - сложный механизм, но благо на 1С уже есть реализации

 



OAuth

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


Из чего состоит авторизационная строка?

  1. OAuth - наименование стандарта
  2. oauth_consumer_key - секретный ключ от провайдера API
  3. oauth_token - токен от провайдера API
  4. oauth_signature_method - метод создания сигнатуры. Про сигнатуру будет далее.
  5. oauth_timestamp - временная отметка в UNIX Time
  6. oauth_nonce - любой уникальный идентификатор
  7. oauth_version - версия API
  8. oauth_signature - сигнатура

Из представленных выше частей наиболее загадочной является сигнатура. Давайте разбираться, что же это такое
 

Сигнатура - хэш, получаемый путем вычисления базовой строки при помощи метода, указанного в поле oauth_signature_method. Что же является базой сигнатуры?

Это соединение через следующих данных:

  • Вида запроса
  • Целевого URL
  • Всех полей авторизационной строки (из списка выше; в виде Ключ=Значение), но без поля oauth_signature
  • Всех не-двоичных полей основного запроса (в виде Ключ=Значение).

При этом, все поля новой строки (кроме URL и вида запроса) должны быть предварительно отсортированы по алфавиту по названиям (ключам) полей и кодированы в кодировке URL. После соединения строки, она должна быть приведена к верхнему регистру

Т.е. после того, как '10 плюс Число полей в запросе минус oauth_signature' пунктов соединены (с кодированием значений в кодировке URL и в расстановке по алфавиту) в одну большую строку вида
 

POST&https%3A%2F%2Fexemple.com&ПОЛЕ1=<ЗНАЧЕНИЕ1>&ПОЛЕ2=<ЗНАЧЕНИЕ2>...OAUTH_CONSUMER_KEY=<КЛЮЧ>&OAUTH_TOKEN=<TOKEN>&OAUTH_TIMESTAMP=<UNIX TIME>&OAUTH_NONCE=<UID>&OAUTH_VERSION=<V>

 

данная строка прогоняется по алгоритму, указанному в oauth_signature_method. Список доступных алгоритмов определяется провайдером API (как правило, это какой-нибудь один метод). Обычно это алгоритмы HMAC и RSA с SHA хэшированием: HMAC-SHA1, HMAC-SHA256 (H256), RSA-SHA256 (R256) и др. - о них мы поговорим на следующем уровне. После прогона строки через алгоритм, полученное значение переводится в Base64Строка и кодируется в кодировке URL

В результате получается хэш, который и является сигнатурой - его значение дописывается в исходную строку:
 

OAuth oauth_consumer_key="<ключ>",oauth_token="<token>",oauth_timestamp="<unix time>",oauth_nonce="<uid>",oauth_version="<v>",oauth_signature="<Наша сигнатура>"

 

Для создания сигнатуры, алгоритму необходима не только база (наша строка), но и ключ - им может выступать строка <oauth_token> &<oauth_consumer_key>. Так или иначе - подобное будет оговорено в документации к конкретному API


Готовая строка передается в заголовке Authorization

Для 1С:

 
 Пример создания заголовка 

 

 


 

OAuth2

Сиквел OAuth, более щадящий в вопросах подготовки запроса, но более сложный в организационных вопросах. При его использовании нет необходимости собирать огромную авторизационную строку как у первого OAuth - используется просто обычный токен (т.е. в вопросах непосредственной отправки запроса, OAuth2 - это Bearer)

Основная суть тут уже в получении и обновлении данного токен. Принцип работы таков:
 

  1. Где-то в настройках API "для разработчиков" указывается redirect_url - адрес вашего ресурса, который будет готов принять внешний запрос с токеном. Говоря просто - это должен быть http-сервис с доступом извне. Т.е. без web-сервера ничего не получится
     
  2. Для получения токена, пользователь в браузере переходит на страницу авторизации и нажимает нечто вроде "Войти"
     
  3. После нажатия кнопки, Http-запрос с токеном отправляется по redirect_url. На нем наш обработчик должен забрать эти данные и сохранить
     
  4. В этом запросе есть два токена - обычный access_token (токен доступа), который и используется как раз для необходимых нам запросов и refresh_token (токен обновления), о котором далее
     
  5. Токен доступа (access_token) - не вечен. Время его жизни оговаривается в документации или летит отдельным полем в запросе из п.4 как expire. Для продолжения работы по истечении срока жизни токена, его необходимо обновить. Для этого отправляется особый запрос к API с refresh_token на борту
     
  6. В ответе этого "особого" запроса приходит новый access_token, а у особо поехавших (привет, Twitter) в некоторых случаях - и новый refresh_token. Все это заменяет прошлые данные
     
  7. Пункты 5 и 6 повторяются периодически
     
    |--> ОбновитьТокен() ->|access_token  --> Используется в т-нии n часов для запросов
    |                      |refresh_token --|
    |--------[через n ч.]-------------------|
    

 

 

На самом деле, все мы сталкиваемся с подобным механизмом каждый день: "Войти при помощи Google/Yandex/VK ID" на разных сайтах - это реализация OAuth2, где сайт, на котором осуществляется вход, также получает токен нашего аккаунта с определенными правами (они, как правило, показываются на панели входа: "Получит доступ к адресу почты", "Получит доступ к номеру телефона" и все такое)
 

Для 1С:

Пример работы с OAuth и OAuth2 есть в реализации API Twitter в ОПИ

Статья по теме 1

Статья по теме 2

 


 

JWT

JWT (JSON Web Tokens) - не стандарт аутентификации, но скорее формат передачи подписанных данных. Готовые токены такого формата могут использоваться для передачи в качестве Bearer 

JWT это JSON данные, состоящие из 3-х частей: заголовка, полезных данных и сигнатуры (подписи) 

 

  • Заголовок (header) - JSON-объект с информацией о способе вычисления подписи
    { "alg": "HS256", "typ": "JWT"}
  • Данные (payload) - JSON-объект непосредственно с полезной нагрузкой
    { "Поле": "Значение" }
  • Подпись (signature) - значение, вычисляемое следующим способом
    СекретныйКлюч = "1111";
    B64Заголовок  = Base64UrlEncode(ПолучитьДвоичныеДанныеИзСтроки(Заголовок));
    B64Данные     = Base64UrlEncode(ПолучитьДвоичныеДанныеИзСтроки(Данные));
    
    НеподписанныйТокен = B64Заголовок + "." + B64Данные;
    
    Сигнатура = Криптография.HMAC(ПолучитьДвоичныеДанныеИзСтроки(СекретныйКлюч)
        , ПолучитьДвоичныеДанныеИзСтроки(НеподписанныйТокен)
        , ХэшФункция.SHA256);
    
    Сигнатура = Base64UrlEncode(Сигнатура);
    
    
    
    ...
    
    Функция Base64UrlEncode(Знач Значение)
    
    	Ответ = Base64Строка(Значение);
    	Ответ = СтрРазделить(Ответ, "=")[0];
    	Ответ = СтрЗаменить(Ответ, Символы.ВК + Символы.ПС, "");
    	Ответ = СтрЗаменить(Ответ, "+", "-"); 
    	Ответ = СтрЗаменить(Ответ, "/", "_"); 
    	Возврат Ответ;
    
    КонецФункции
    

 

Сам токен - соединение всех частей через точку
 

Токен = Заголовок + "." + Данные + "." + Сигнатура;

 

Далее его можно использовать по прямому назначению

 

Для 1С:
Open-source библиотека для JWT в 1С
Статья по теме
Конструктор JWT на jwt.io


 

Помимо этих вариантов есть еще схемы: MutualHOBA, VAPID и др., но вероятность встретить подтверждение личности по паспорту в реальной жизни куда выше, чем их реализацию в публичном API. И если некоторые из них (например Mutual) в реальном мире на самом деле существуют, просто под капотом интернета, то найти хотя бы теоретическую информацию о том, что же такое HOBA, вообще крайне сложно
 

 

Уровень 3 - Алгоритмы

На предыдущем уровне в некоторых из схем нам встречалось создание сигнатур. При работе с каждой из них, в зависимости от воли провайдера API, требуется применение того или иного алгоритма обработки данных. Наиболее распространенными из них на данный момент являются HMAC и RSA, в вариациях, основанных на различных алгоритмах хэширования - HMAC-SHA1, RSA-SHA256 и др. О них и поговорим

HMAC

HMAC (Hash-based message authentication code) - один из самых популярных механизмов проверки целостности информации. Я не буду рассказывать прохладные истории, будто бы понимаю (или должен понимать) как он внутри работает - никому из нас, я думаю это и не нужно. Как и в любых подобных вещах, 95% HMAC - это зубодробительный МАТАН, так что лучше сразу перейдем к 1С

Тут нам повезло гораздо больше (спойлер) чем с алгоритмом RSA: в Библиотеке стандартных подсистем, а именно в модуле РаботаВМоделиСервисаБТС есть замечательная, но, почему-то не экспортная, функция
 

HMAC(Знач Ключ, Знач Данные, Тип, РазмерБлока)


В параметре Тип она принимает значение платформенного перечисления ХешФункция (ХешФункция.SHA1, ХешФункция.SHA256, ХешФункция.SHA512) от которого и будет зависеть, собственно, будет у нас HMAC-SHA256, HMAC-SHA512 или HMAC-SHA1. А большего тут и не надо

 

RSA

RSA используется не так часто, как HMAC, но зато печально известно в мире 1С своим применением в сервисах от Google, когда речь заходит о работе через Service account. В 1С нет реализации RSA и лично я встречал всего несколько вариантов решений данной проблемы:

  • В репозитории malikov-pro/google_api_1c можно найти подобное решение
     
    Функция ПолучиьПодписьRSASHA256(СтрокаДанные, КлючПодписи_XML) Экспорт
    	
    	Хеширование = Новый ХешированиеДанных(ХешФункция.SHA256);
    	Хеширование.Добавить(СтрокаДанные);
    	ХешДвоичный = Хеширование.ХешСумма;
    	
    	КриптоПровайдер = Новый COMОбъект("System.Security.Cryptography.RSACryptoServiceProvider");
    	КриптоПровайдер.FromXmlString(КлючПодписи_XML);
    	
    	SafeArrayBinХешДляПодписи = SafeИзДвоичных(ХешДвоичный);
    	SafeArrayBinПодписьДвоичная = КриптоПровайдер.SignHash(SafeArrayBinХешДляПодписи, "SHA256");
    	
    	Возврат ДвоичныеИзSafe(SafeArrayBinПодписьДвоичная);
    	
    КонецФункции


    Тут используется COM объект, что не очень хорошо, но выглядит довольно просто и под Windows будет работать

  • Dll на Инфостарте. Скажу честно - не проверял

  • Формирование объекта через новый платформенный объект ТокенДоступа. Есть недавняя статья на эту тему, но подойдет только тем, у кого свежая версия 1С (в статье 8.3.21) 

  • Есть пример решения на Python, интегрированного в решение для Google Sheets на 1С от Евгения Комиссарова

 

Возможно есть и другие, но я о них не знаю. Хотя очень искал, когда начинал делать интеграцию с Google Drive

Другие же алгоритмы на практике встречаются гораздо реже

 

В заключении

В принципе, это все, что я хотел рассказать. Если я что-то упустил или вы нашли ошибку - напишите в комментариях. Также ниже будет список полезных ресурсов, который могут помочь при работе с API. Список будет дополняться, так что если знаете еще что-нибудь - об этом можете написать также
 

Спасибо за внимание!

 

 

 Мой GitHub:     https://gitub.com/Bayselonarrend 
 Лицензия MIT:   https://mit-license.org

web api авторизация rest rest api oauth bearer token аутентификация интеграция обмен сервисы http https

См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Системный администратор Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020    16230    14    18    

14

Интеграция 1С и Битрикс 24 — модуль синхронизации для обмена задачами

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс 24. Разработка имеет двухстороннюю синхронизацию 1С и Bitrix24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (платформа начиная с 8.3.23). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    18398    10    15    

16

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    13076    34    8    

13

Автоматическая загрузка файлов (например, прайс-листов) из электронной почты, FTP, HTTP, их обработка и выгрузка на FTP (на сайт) и для других целей

Прайсы WEB-интеграция Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Автомобили, автосервисы Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Программа с заданным интервалом времени (или по ручной команде) скачивает файлы (например, прайс-листы поставщиков) из различных источников: письма электронной почты, FTP или HTTP-адреса, и сохраняет их в каталог упорядоченной структуры. При этом извлекает файлы из архивов, может переименовывать файлы и менять их формат (csv, xls, txt). Можно настроить выгрузку обработанных файлов на сайт (через FTP-подключение). Программа будет полезна компаниям, у которых есть большое количество поставщиков и/или прайс-листы поставщиков обновляются часто (необязательно прайс-листы, файлы могут быть любого назначения). Собранные таким образом актуальные версии прайс-листов можно выгрузить с помощью программы себе на сайт (или на любой FTP-сервер) или выполнить другие необходимые задачи.

25200 руб.

28.05.2015    85702    26    51    

50

Интеграция с сервисом vetmanager

WEB-интеграция Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16722    43    49    

24
Вознаграждение за ответ
Показать полностью
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Dzenn 876 22.04.24 14:47 Сейчас в теме
Начал читать, и что-то мне подсказывает, что после освоения я разберусь во всём этом. Спасибо тебе, добрый человек.
bayselonarrend; +1 Ответить
2. Silenser 597 22.04.24 17:41 Сейчас в теме
Круто. Если будет возможность, можете сюда же добавить TOTP / OTP. По идее, это то же входит в этот же контекст.
5. bayselonarrend 1364 22.04.24 18:51 Сейчас в теме +5 $m
(2) Постараюсь, но надо разбираться - на практике мне не встречался до этого
3. Dzenn 876 22.04.24 17:48 Сейчас в теме
Автор, "Коннектор" это тоже твоё?
4. bayselonarrend 1364 22.04.24 18:50 Сейчас в теме
6. kalyaka 1079 22.04.24 19:19 Сейчас в теме
Спасибо за структурированную подачу материала. Наконец то я понял, что за "медведя" всегда использовал :)
bayselonarrend; +1 Ответить
7. efin 23.04.24 23:37 Сейчас в теме
Для Basic необходимо пару логин:пароль обернуть в base64
bayselonarrend; +1 Ответить
8. bayselonarrend 1364 24.04.24 09:00 Сейчас в теме
(7)Да, пропустил момент. Спасибо
10. efin 24.04.24 12:22 Сейчас в теме
(8)
Можно вот так
Basic = Base64Строка(ПолучитьДвоичныеДанныеИзСтроки(Basic));
и тогда переносы строк убирать не придется, сэкономите 2 строки кода
SOLTAN; NicolasCage; bayselonarrend; +3 Ответить
9. soulner 393 24.04.24 11:58 Сейчас в теме
Всем добрый день, хочется немного добавить.
1. Полный формат сетевого имени Логин:Пароль@ИмяСервера.Домен, и когда мы используем объект HTTPСоединение с указание логина и пароля, то авторизация происходит именно таким способом. Автор использовал Basic-авторизацию через заголовок HTTPЗапроса, так тоже иногда работает, но про указание имени и пароля в HTTPСоединении нельзя забывать. Так работает авторизация в 1С и SAP, например.
2. Как понять какая авторизация нужна web-сервису, а нужно выполнить к нему запрос и получить ошибку 401, а в заголовке ответа будет строка WWW-Authenticate, в которой указывается тип авторизации и приложение (или каталог), которое его требует.
А так, хорошая статья, плюсанул.
SOLTAN; bayselonarrend; +2 Ответить
11. kamisov 154 28.04.24 09:13 Сейчас в теме
Благодарю за статью!

Немного дополню:

1. HMAC уже начинают считать устаревшим. Например в новых версиях Hashicorp Vault вы не авторизуетесь по JWT с HMAC подписью, так как библиотека go-jose перестала поддерживать это. https://github.com/hashicorp/vault-plugin-auth-jwt/pull/290
2. Токен доступа в 1С полноценно работает с 8.3.24. До этой версии он делает поля iat и exp не числами, а строками, на чем та же go-jose падает. Тут ничего нового, 1С как обычно реализовала стандарт в своем уникальном прочтении. Спасибо что исправились.
itmind; bayselonarrend; +2 Ответить
12. Cyberhawk 135 14.05.24 09:06 Сейчас в теме
аутентификация будет пройдена успешна
bayselonarrend; +1 Ответить
Оставьте свое сообщение