Что такое HMAC и JWT и как это использовать в 1С

Обмен - Обмен с другими системами

Лёгкая статья про стандарты HMAC и JWT с небольшой теорией и исходным кодом.

Лёгкая статья про стандарты HMAC и JWT с небольшой теорией и исходным кодом.

Коллеги, позвольте вам рассказать о вещах, которые далеки от обычной разработки в 1С.

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

Часть первая, теоретическая.

HMAC (Hash-based message authentication code) - это хэш, который вычисляется, основываясь на двух значениях: 'ключ' и 'сообщение'. Такой хэш нужен, чтобы гарантировать, что данные, передаваемые в ненадежной среде, не были изменены посторонними лицами.

Зачем же нам использовать HMAC, когда у нас есть, например, HTTPS?

HMAC полезен, когда участников в обмене сообщениями больше, чем два.

Например, у нас есть три участника:

  •  'Провайдер API' - сторонний сервис, который принимает запросы на отправку открыток и букетов
  •  'Сервер' - серверная часть вашего приложения
  •  'Клиент' - клиентская часть, с которой работают пользователи

'Провайдер API' предоставляет две вещи для выполнения запросов – это AccounID и SecretKey. 'Провайдер API' ни чего не знает про ваших пользователей, чтобы принять запрос на отправку открытки, ему нужно удостовериться, что просящий знает AccounID и SecretKey.

'Сервер' в свою очередь должен управлять тем, какие пользователи имеют право отправлять букеты, а каким разрешены только открытки.

Разумеется, очевидное решение задачи заключается в том, чтобы все клиентские запросы направить через 'Сервер':

  1.  'Клиент' - формирует запрос на отправку открытки для 'Сервера';
  2.  'Сервер' - проверяет права конкретного пользователя и если всё хорошо, то перенаправляет вызов на 'Провайдера API';
  3.  'Провайдер API' делает необходимые действия;
  4. Далее по цепочке обратно передается результат вызова.

Но что, если у нас клиенты генерируют десятки тысяч таких запросов, и не хотят долго ждать результат выполнения? Или наши запросы содержат потоковое аудио (для музыкальных открыток), которым не хотелось бы грузить 'Сервер'? Более того, а что, если 'Клиент' передает конфиденциальные сведения, которые и вовсе не должны попасть на 'Сервер' (букет с интимным посланием)?
Почему бы нам сразу не слать запросы с 'Клиента' на 'Провайдер API'?

Тогда нам придется 'Клиенту' сообщить AccounID и SecretKey, которые нужны 'Провайдеру API'. Но поскольку у нас разные клиенты имеют разные права (открытки, букеты) и в какой то момент у клиента права могут быть и вовсе отозваны, то мы не можем сообщать 'Клиенту' AccounID и SecretKey.
В этот момент нам и пригодится HMAC.
Благодаря HMAC мы можем построить работу следующим образом:

  1. 'Клиент' запрашивает у 'Сервера' специальный Token
  2. 'Сервер' делает Token с помощью HMAC, учитывая права пользователя и ограничивая действие токена по времени:
Token = HMAC(SecretKey, AccounID + ПравоПользователя + ДатаВремяДоступа)

Теперь пользователь может обратиться напрямую к 'Провайдеру API' за конкретной услугой и предоставить Token, AccounID и ДатаВремяДоступа. 'Провайдер API' вычисляет Token и сверяет его с тем, что прислал 'Клиент' и той услугой которую 'Клиент' хочет получить.

В данной схеме 'Клиент' является той самой ненадежной средой. Фактически запрос должен делать 'Сервер', потому что 'Провайдер API' сказал свой SecretKey только 'Серверу'. Но наш 'Сервер' не хочет делать запросы и разрешает на время 'Клиенту' самостоятельно делать запросы. Наш 'Сервер' не доверяет 'Клиенту' и использует HMAC, чтобы обеспечить неизменность выданных разрешений на использование услуг 'Провайдера API'.


Часть вторая, считаем HMAC.

Давайте посмотрим под капот и узнаем, что же внутри функции HMAC.

Функция HMAC на вход принимает SecretKey и Message типа ДвоичныеДанные и вид хэш функции.

Function HMAC(Val SecretKey, Val Message, Val HashFunc)
	
	// Определяем размер блока согласно стандарту RFC 2104 https://www.ietf.org/rfc/rfc2104.txt
	If HashFunc = HashFunction.MD5 Then
		BlSz = 16;
	ElsIf HashFunc = HashFunction.SHA1 Then
		BlSz = 20;
	ElsIf HashFunc = HashFunction.SHA256 Then
		BlSz = 64;
	Else
		Raise "HMAC: unsupported hash function: " + HashFunc;
	EndIf;

	// Обрезаем ключ до размера блока
    SecretKey = BinLeft(SecretKey, BlSz);
	
	// Если ключ меньше блока, то добиваем его нулями до размера блока
	К0 = BinRightPad(SecretKey, BlSz, "0x00");
	
	// Делаем k_ipad, выполняем операцию «побитовое исключающее ИЛИ» ключа c константой 0x36
	ipad = BinRightPad(,BlSz, "0x36");
	k_ipad = BinBitwiseXOR(К0, ipad);
	
	// Делаем k_opad, выполняем операцию «побитовое исключающее ИЛИ» ключа c константой 0x5c
	opad = BinRightPad(,BlSz, "0x5C");
	k_opad = BinBitwiseXOR(К0, opad);
	
	// склеиваем k_ipad и сообщение
	k_ipad_Message = BinConcat(k_ipad, Message);
	
	// вычисляем хэши и получаем результат
	k_opad_Hash = BinConcat(k_opad, Hash(k_ipad_Message, HashFunc));
	Return Hash(k_opad_Hash, HashFunc);
	
EndFunction

Функции BinLeft, BinRightPad, BinBitwiseXOR и BinConcat реализованы с использованием возможностей платформы, которые появились в версии 8.3.10.2168.

Теперь мы можем делать хэш и комбинировать данные для подписи любым способом.

Например, так:

Token = HMAC(SecretKey, AccounID + ПравоПользователя + УникальныйИдентификатор + "допДанные7" + ДатаВремяДоступа + ИмяПользователя)

Такая свобода действий может породить хаос и как следствие – увеличение сроков разработки и интеграции. Что, если бы у нас был стандарт, по которому определен формат для сообщений?

Такой стандарт у нас есть, и называется он JWT.


Часть третья, пару слов про JWT

JWT (JSON Web Token) – это стандарт, по которому определено, в каком виде будет выглядеть токен для клиента. По сути JWT это строка, состоящая из трех частей соединенных точками: заголовок, данные и подпись.

Например: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Этот токен содержит:

заголовок (Header)

{
  "alg": "HS256",
  "typ": "JWT"
}

данные (Payload)

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

и подпись (Signature):

TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

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

К этой статье приложена реализация JWT на чистом 1C:Enterprise 8.3.10.2168.


Например, вы делаете интеграцию со сторонним сервисом, и вам необходимо договорится об авторизации запросов от пользователей. С большой вероятностью сторонний сервис реализован на платформе, для которой есть готовая библиотека JWT. Вы как прогрессивный разработчик 1С теперь можете предложить использовать стандарт RFC 7519 – т.е. JWT. Каждый со своей стороны возьмет готовую библиотеку и вуаля – пользователи ходят напрямую в сторонний сервис.

Заключение

Благодарю, что прочитали эту статью. Надеюсь, вы нашли для себя полезное.

Пожалуйста, напишите в комментариях, как по вашему мнению можно было бы использовать JWT в мире 1С уже сейчас.

Любые, возможно бредовые, идеи принимаются. Например: отправка whatsapp-сообщений прямо из тонкого клиента.

P.S.

Позвольте сказать, что я открыт для предложений о трудоустройстве и сотрудничестве. Если вы делаете приложения 1С и все объекты у вас на английском – пожалуйста напишите мне на почту vasily@pintov.ru.

Скачать файлы

Наименование Файл Версия Размер
Обработка содержащая код для работы с HMAC и JWT
.epf 9,40Kb
19.04.17
20
.epf 1.0 9,40Kb 20 Скачать

См. также

Лучшие комментарии
1. Призрак (davdykin) 17 21.04.17 21:42 Сейчас в теме
Спасибо за информацию, учитывая популярность микросервисов думаю может вполне пригодиться.
Остальные комментарии
1. Призрак (davdykin) 17 21.04.17 21:42 Сейчас в теме
Спасибо за информацию, учитывая популярность микросервисов думаю может вполне пригодиться.
2. Stas Bor (stas1976) 14 26.04.17 11:23 Сейчас в теме
3. Александр (NcSteel) 04.05.17 20:58 Сейчас в теме
Подскажите, пожалуйста, вариацию если в качестве соли используется не строковый ключ, а сертификат
4. - - (user757186) 29.06.17 19:49 Сейчас в теме
(3) функции хэширования и подписи работают с двоичными данными, строки - это лишь частный случай двоичных данных. Если вы посмотрите внимательно код - там нет фукнкций работы со строками, там используются функции работы с двоичными данными.
5. Петр Базелюк (pbazeliuk) 1342 17.10.17 10:19 Сейчас в теме
Для MD5 и SHA-1 у вас не верный размер блока, он должен быть 64. Можете проверить в любом онлайн генераторе.
7. Василий Пинтов (keypax) 58 18.10.17 10:51 Сейчас в теме
6. Петр Базелюк (pbazeliuk) 1342 17.10.17 11:36 Сейчас в теме
И последнее, если ключ больше размера блока, его необходимо предварительно хешировать
Оставьте свое сообщение