Плюсы и минусы JWT: краткий обзор тонкостей этой технологии

В этой статье представлен анализ JWT (JSON Web Tokens, правильно произносится как «джот») — начиная с того, как они используются, и заканчивая плюсами и минусами использования JWT в вашем приложении. В последнее время аутентификация через JWT стала невероятно популярна, между тем, многие начинающие программисты не до конца понимают, что кроме очевидных плюсов у этого подхода есть и минусы. Мы постарались максимально визуализировать схемы и логики работы авторизации, чтобы наш анализ был максимально понятным и простым для читателя.

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

Один из способов описания JWT заключается в том, что он  является «переносимыми единицами идентификации». Это означает, что токены содержат информацию об идентификации в формате JSON и могут универсальным способом передаваться службам и приложениям. Любой сервис или приложение может самостоятельно проверить JWT. Службе/приложению, получающему JWT, не нужно спрашивать поставщика идентификационных данных, создавшего JWT, действителен ли он. После проверки JWT-служба или приложение может использовать содержащиеся в нем данные для выполнения действий от имени пользователя.

Вот общая диаграмма, иллюстрирующая, как поставщик идентификационных данных создает JWT и как служба может использовать JWT, не обращаясь к поставщику идентификационных данных (да, на диаграмме изображен Palm Pilot):

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

Вот диаграмма, иллюстрирующая, как вызывается поставщик идентификационных данных для проверки непрозрачного токена и для получения данных пользователя:

Этот метод проверки и обмена токенами может быть очень «болтливым», создавая определенный оверхед. Кроме того, он также требует метода сохранения и загрузки токенов внутри провайдера идентификации. JWT-токены, с другой стороны, не требуют сохранения или специфической логики в провайдере идентификации, поскольку они переносимы и универсальны.

Есть несколько моментов, которые следует учитывать при принятии решения об использовании JWT. Давайте рассмотрим несколько основных из них.

Срок действия JWT истекает через определенные промежутки времени

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

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

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

Чтобы решить эту проблему, большинство приложений используют маркеры обновления. Маркеры обновления — это непрозрачные токены, которые используются для генерации новых JWT. Срок действия маркеров обновления также должен истечь в определенный момент, но они могут быть более гибкими в этом механизме, поскольку хранятся в провайдере идентификации. Это также делает их похожими на стандартные непрозрачные токены, описанные выше.

JWT подписываются

Поскольку JWT подписаны криптографически, для их проверки требуется аналогичный криптографический алгоритм. Криптографические алгоритмы специально разрабатываются так, чтобы быть медленными. Чем медленнее алгоритм, тем выше сложность, и тем меньше вероятность того, что алгоритм можно взломать методом перебора (brute force).

На четырехъядерном MacBook Pro можно создать и подписать около 200 JWT в секунду с помощью RSA с открытым и закрытым ключом. Это число резко снижается на виртуализированном оборудовании, таком как Amazon EC2s. Подписание HMAC намного быстрее, но не обладает такой же гибкостью и характеристиками безопасности.

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

Чтобы дать вам представление о характеристиках производительности JWT и используемых криптографических алгоритмах, мы провели несколько тестов на четырехъядерном MacBook. Вот замеры, которые мы получили при массовом создании JWT (в формате метрика/тайминг):

• Сериализация JSON + кодирование Base64 — 400,000/s
• Сериализация JSON + кодирование Base64 + подписание HMAC — 150,000/s
• Сериализация JSON + кодирование Base64 + подписание RSA — 200/с
• Декодирование Base64 + парсинг JSON — 400,000/s
• Декодирование Base64 + парсинг JSON + проверка HMAC — 130,000/s
• Декодирование Base64 + парсинг JSON + верификация RSA — 6,000/s

JWT нельзя легко отозвать

Это означает, что JWT может быть действительным, даже если учетная запись пользователя была приостановлена или удалена. Есть несколько способов обойти это, включая «событие отзыва обновленного токена» в сочетании с webhook. Это решение, например, доступно в FusionAuth.

JWT имеют уязвимости

Это скорее вопрос плохого кодирования, чем недостатков, присущих JWT. Алгоритм «none» и взлом «HMAC» — хорошо известные случаи использования JWT. Я не буду вдаваться в подробности об этих уязвимостях, но если немного поискать, то можно найти множество обсуждений.

Обе эти атаки имеют простые исправления. В частности, вы никогда не должны разрешать JWT-токены, которые созданы с использованием алгоритма «none». Также не следует слепо загружать ключи/подписи, используя заголовок «kid» в JWT. Вместо этого следует дополнительно проверить, что ключ действительно является правильным ключом для алгоритма, указанного в заголовке.

Сессии как альтернатива

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

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

 

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

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

Подведение итогов

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

В заключении еще раз стоит отметить, что по умолчанию JWT не шифруются (режим none), и что строка, которую мы видим, является просто сериализацией в кодировке base64url, которую можно легко декодировать, чтобы увидеть обычное содержимое JSON, которое несет токен.

Поэтому ответ на первоначальный вопрос статьи о безопасности JWT звучит так: «Это зависит от…». Как и многие другие технологии, JWT в значительной степени зависит от хорошей конфигурации при выпуске токенов, а также от правильного использования и корректной валидации потребляемых извне токенов.

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

• APICheck состоит из набора небольших инструментов, которые могут быть соединены в цепочку для выполнения нескольких тестов на API-запросы.
• После этого мы также занялись разработкой нового инструмента для проверки JWT, jwt-checker, в котором мы реализовали возможность прохождения проверки на корректность токенов.