Буквы префикса представляют семейство алгоритмов подписи, которое можно кратко объяснить как
HS - HMAC
RS - RSA
ES - ECDSA
PS - RSA-PSS (RSA-вероятностная схема подписи)
Следующая цифра представляет длину значения HASH, сгенерированного соответствующим алгоритмом, в качестве примера HS256 обозначает HMAC-SHA256 .
Алгоритмы HMAC
Это, вероятно, самый распространенный алгоритм для подписанных JWT.
Коды аутентификации сообщений на основе хэша (HMAC) представляют собой группуалгоритмы, которые обеспечивают способ подписи сообщений с помощью общего ключа. В случае HMAC используется криптографическая хеш-функция (например, SHA256). Сила (то есть, насколько трудно подделать HMAC) зависит от используемого алгоритма хеширования.
Алгоритмы RSA и ECDSA И RSA, и ECDSA являются алгоритмами асимметричного шифрования и цифровой подписи. Партия использует свою частную вечеринку для подписания JWT. Получатели, в свою очередь, используют открытый ключ (который должен совместно использоваться так же, как общий ключ HMAC) этой стороны для проверки JWT. Принимающие стороны не могут создавать новые JWT, используя открытый ключ отправителя.
Оба алгоритма RSA и ECDSA более сложны, чем HMAC.
Основное различие между RSA и ECDSA заключается в скорости и ключе. размер. ECDSA требует меньших ключей для достижения того же уровня безопасности, что и RSA. Это делает его отличным выбором для небольших JWT. RSA, однако, обычно быстрее, чем ECDSA. Как обычно, выберите тот, который лучше всего соответствует вашим требованиям.
RSA-PSS стандартизирован как часть PKCS # 1 v2.1. Цифровая подпись RSA-PSS SHA-256 для JWS проверяется следующим образом: отправьте вход для подписи JWS, подпись JWS и открытый ключ, соответствующий закрытому ключу, используемому подписывающим, в алгоритм RSA-PSS-VERIFY с использованием SHA-256 в качестве хэш-функции.
Подписание и проверка с использованием алгоритмов RSA-PSS SHA-384 и RSA-PSS SHA-512 выполняется идентично процедуре для RSA-PSS SHA-256 - просто с использованиемальтернативный алгоритм хеширования в обеих ролях.
Безопасность хранения файлов cookie JWT
И, чтобы ответить на ваш последний вопрос, файлы cookie, если они используются с флагом cookie HttpOnly, не доступны черезJavaScript и иммунитет к XSS. Вы также можете установить флажок Безопасный файл cookie, чтобы гарантировать, что файл cookie отправляется только через HTTPS. Это одна из главных причин того, что в прошлом cookie-файлы использовались для хранения токенов или данных сеанса. Современные разработчики не решаются использовать куки, потому что они традиционно требуют, чтобы состояние сохранялось на сервере, тем самым нарушая лучшие практики RESTful. Файлы cookie как механизм хранения не требуют сохранения состояния на сервере, если вы сохраняете JWT в файле cookie. Это связано с тем, что JWT инкапсулирует все, что нужно серверу для обслуживания запроса.
Однако файлы cookie уязвимы для другого типа атаки: подделка межсайтовых запросов (CSRF). CSRF-атака - это тип атаки, которая происходит, когда вредоносный веб-сайт, электронная почта или блог заставляют веб-браузер пользователя выполнять нежелательные действия на доверенном сайте, на котором пользователь в настоящий момент проходит проверку подлинности. Это эксплойт того, как браузер обрабатывает куки. Файл cookie может быть отправлен только на те домены, на которых он разрешен.
CSRF можно предотвратить с помощью синхронизированных шаблонов токенов. Это звучит сложно, но все современные веб-фреймворки поддерживают это.