PASETO

Platform-Agnostic Security Tokens, разработанные Скоттом Арсишевски (Scott Arciszewski, Paragon Initiative) как прямой ответ на проблемы в архитектуре JWT и семейства JOSE в целом. Спецификация опубликована на paseto.io. PASETO - это рекомендация, на которую ссылаются gist samsch и похожие критические разборы везде, где действительно нужен короткоживущий подписанный токен: разумная замена JWT для тех случаев, где подписанные токены действительно к месту.

PASETO - это не замена механизму управления сессиями. Он не отменяет базового аргумента: для поддержания сессий пользователей в браузере нужно использовать сессии на cookie и избегать JWT в качестве сессионных токенов. PASETO - инструмент для оставшихся сценариев с временем жизни порядка пяти минут: транспорт в SSO, ссылки для сброса пароля, ссылки подтверждения почты, capability-токены, межсервисная аутентификация.

Что не так с JWT и как это исправляет PASETO

Архитектура PASETO построена как список решений, принятых в противовес JWT:

Никакого поля alg, никакого согласования алгоритмов. Идентификатором служат версия и назначение (purpose) токена. Нельзя попросить проверяющую сторону использовать более слабый алгоритм, нельзя перепутать симметричный ключ с асимметричным (атака key confusion в JOSE), и нет никакого alg: none.
Версионированные криптографические наборы. Каждая версия PASETO жёстко закрепляет конкретные алгоритмы. Актуальны v3 и v4: v3 для наборов NIST (P-384 ECDSA, AES-CTR + HMAC), v4 для современных не-NIST (Ed25519, XChaCha20). Здесь нет выбора алгоритма на уровне отдельного токена, в котором можно ошибиться.
Ровно два назначения. local (симметричное шифрование) и public (асимметричная подпись). Всё. Матрица вариантов JOSE из JWS x JWE x алгоритмы сворачивается в четыре чётко определённые комбинации на две версии.
Аутентифицированное шифрование по умолчанию для симметричного случая. PASETO v4.local использует XChaCha20-Poly1305. В JWE сделать это с ошибкой можно множеством способов.
Footer'ы и неявные утверждения (implicit assertions) для привязки токенов к конкретному контексту (аудитория, издатель, идентификатор ключа), при этом сами эти значения не попадают в изменяемый набор claims.

Как это выглядит

Внешне токены PASETO похожи на JWT - сегменты в base64url, разделённые точками, - но версия и назначение закодированы прямо в начале:

v4.public.eyJkYXRhIjoidGhpcyBpcyBhIHNpZ25lZCBtZXNzYWdlIn0.<sig>

Первые два сегмента (v4.public) - это версия и назначение; всё остальное однозначно следует из этого выбора. Проверяющая сторона не считывает подсказку об алгоритме из токена; она точно знает, какой алгоритм соответствует v4.public, и откажется проверять токен любым другим.

Когда стоит выбрать PASETO

Передача данных в системах SSO - короткоживущие bearer-токены, передающие статус входа с одного хоста или сервиса на другой.
Токены сброса пароля, magic link'ов и подтверждения email.
Подписанные capability-токены (ссылки на скачивание, токены действий со встроенным сроком действия).
Межсервисная аутентификация в микросервисной архитектуре (альтернатива mTLS или JWT).

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

Когда PASETO выбирать не стоит

Для управления сессиями в браузере используйте cookie-session-auth. PASETO не решает проблему несоответствия времени жизни и проблему того, что "stateless - это иллюзия", из-за которых не стоит использовать jwt-for-sessions - эти свойства присущи самой идее bearer-токенов в долгоживущих сессиях, какой бы формат подписанных токенов для них ни был выбран.

Связанные страницы

jwt-for-sessions - антипаттерн, который PASETO не исправляет; для сессий всё ещё нужны cookie
cookie-session-auth - подходящий инструмент для сессий в браузере
samsch-jwt-auth-gist - короткий gist, рекомендующий PASETO для оставшихся сценариев с короткоживущими токенами