Аутентификация на основе токенов и HMAC
(продолжение предыдущего поста)

Аутентификация на основе токенов и аутентификация HMAC являются распространенными формами аутентификации. Посмотрим, в чем они различаются.

1. Принцип работы

- Аутентификация на основе токенов (Token-based authentication):
1. Клиент отправляет логин и пароль на Authentication Server.
2. Сервер аутентификации генерирует токен (уникальную строку) и передаёт его клиенту.
3. Клиент включает токен в заголовки HTTP-запросов к Web Server при обращении к ресурсам.
4. Web Server проверяет валидность токена и, если он действителен, предоставляет доступ к ресурсу.

Суть: клиент получает токен после успешной аутентификации и использует его для подтверждения своих прав при каждом запросе.

- Аутентификация на основе HMAC (HMAC authentication):
1. Клиент запрашивает API key у Authentication Server.
2. Сервер передаёт клиенту API key (секретный ключ).
3. Клиент генерирует HMAC-подпись (hmac A) на стороне клиента, используя API key и параметры запроса (например, URI, метод HTTP, временная метка).
4. Клиент отправляет запрос к Web Server вместе с HMAC-подписью.
5. Web Server генерирует свою HMAC-подпись (hmac B) с теми же параметрами, используя свой экземпляр API key.
6. Web Server сравнивает hmac A (от клиента) и hmac B (собственно сгенерированный). Если подписи совпадают — запрос считается аутентифицированным.
7. При успешной проверке клиент получает доступ к ресурсу.

Суть: клиент и сервер независимо вычисляют HMAC-подпись, используя общий секретный ключ. Совпадение подписей подтверждает подлинность запроса.

2. Используемые механизмы безопасности

- Токены:
- Используют систему «выдать и использовать» (token issuance and validation).
- Токены могут быть JWT (JSON Web Tokens) с подписями, которые содержат метаданные (истечение срока действия, идентификатор пользователя и т. д.).
- Защита строится на валидации подписи токена и его срока действия.

- HMAC:
- Основан на криптографической функции HMAC (Hash-based Message Authentication Code), которая сочетает хэш-функцию и секретный ключ.
- Гарантирует целостность данных (данные не изменены в пути) и аутентичность отправителя (только владелец секретного ключа может сгенерировать корректную подпись).
- Секретный ключ никогда не передаётся в открытом виде — только используется для генерации подписей.

3. Этапы взаимодействия

- Токены: 4 основных шага (вход → получение токена → отправка запросов с токеном → доступ к ресурсу).
- HMAC: 7 шагов, включая генерацию и сравнение подписей (запрос API key → генерация подписи клиентом → отправка запроса → генерация подписи сервером → сравнение подписей → доступ к ресурсу).

4. Уровень сложности и вычислительных затрат

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

5. Сценарии применения

- Токены: подходят для веб-приложений, мобильных приложений, где важна простота и скорость аутентификации. Часто используются в REST API, SPA (Single Page Applications).
- HMAC: предпочтителен для API, где критична безопасность (финансовые сервисы, платёжные системы), а также для микросервисов, где требуется строгая проверка целостности запросов.

6. Уязвимости и защита

- Токены: уязвимы к перехвату (если не используются защищённые каналы, например, HTTPS). JWT могут быть подвержены атакам, если подпись не проверена должным образом.
- HMAC: более устойчив к перехвату, так как даже зная запрос, злоумышленник не сможет сгенерировать корректную подпись без секретного ключа. Однако требует строгой защиты API key.

Краткое резюме:
- Токены — удобны и быстры, но менее безопасны.
- HMAC — более сложен в реализации, но обеспечивает высокий уровень защиты за счёт криптографической проверки целостности и подлинности. Выбор зависит от требований к безопасности и архитектуры системы.