JWT против аутентификации сессий

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

Поскольку HTTP по своей природе является статeless, каждый запрос в сессии независим и не запоминает информацию из предыдущих. Повторная аутентификация пользователей для каждого действия затруднительна и ухудшает пользовательский опыт.

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

Что такое аутентификация на основе сессий?#

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

Как работает аутентификация на основе сессий?#

Создание сессии

1. Пользователь аутентифицируется и предоставляет некоторые учетные данные (например, электронную почту и пароль).
2. Если учетные данные действительны, сервер создает постоянную запись, представляющую эту сессию. Сессия содержит информацию, такую как случайная строка, идентификатор пользователя, время начала сессии, время истечения сессии и т.д.
3. SessionID сохраняется в базе данных и возвращается на клиент пользователя в виде cookie.

Проверка сессии

1. Процесс может быть инициирован вручную пользователем (например, нажатием вкладки, обновлением страницы) или автоматически клиентом (например, во время первоначальной загрузки страницы или через API-вызовы с SessionID).
2. Каждый последующий вызов отправляет HTTP-запрос от клиента, содержащий cookie сессии, на сервер.
3. Сервер проверяет действительность SessionID, консультируясь с данными сессии, хранящимися на сервере.
4. Если действителен, сервер обрабатывает запрос и авторизует пользователя.

Как отозвать сессию?#

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

• Пользователь выходит вручную: Сервер удаляет запись сессии, тем самым отключая пользователя.
• Администраторы принудительно отключают пользователя: Администраторы или системы могут завершить конкретную сессию, удалив ее из базы данных. Например, во время взлома безопасности.
• Истечение срока действия сессии: Сессии могут автоматически истекать после установленного времени неактивности или фиксированного временного лимита.

Преимущества аутентификации на основе сессий#

• Простота и надежность: Запись сессии предоставляет четкий, централизованный источник, что позволяет более надежно принимать решения о авторизации.
• Аннулирование в реальном времени: Удалив или аннулировав запись сессии, доступ пользователя можно быстро отозвать.

Недостатки аутентификации на основе сессий#

• Задержка в распределенной системе: Поддержание данных сессии на нескольких серверах всегда требует синхронизации хранилища сессий. Это вызывает дополнительную задержку, потому что сервер должен проверять хранилище сессий каждый раз, когда выполняется запрос.
• Высокое потребление ресурсов: Каждая сессия занимает ресурсы сервера, что снижает производительность при увеличении числа пользователей.
• Риск безопасности: Похищение сессий (через украденные cookie сессии) может позволить получить несанкционированный доступ к учетным записям пользователей.
• Ограниченное использование для API: Аутентификация на основе сессий не очень подходит для мобильных приложений. Она хранит данные сессии на сервере, что может увеличить нагрузку и сложность при большом количестве пользователей. Плюс, она использует cookie, которые сложнее обрабатывать на мобильных устройствах.

Что такое аутентификация JWT?#

JSON Web Tokens (JWT) используют другой подход, внедряя всю релевантную информацию о пользователе непосредственно в токен, используя JSON объект. В отличие от методов на основе сессий, JWT являются stateless, что означает, что сервер не управляет записями аутентификации.

Как работает аутентификация JWT?#

JWT состоит из трех частей: заголовок, полезная нагрузка и подпись.

• Заголовок содержит алгоритм подписи (например, HS256) и тип токена (JWT).
• Полезная нагрузка содержит основные претензии, такие как идентичность пользователя, роль пользователя и время истечения срока действия.
• Подпись использует ключ для подписания заголовка и полезной нагрузки, что позволяет проверить, была ли подпись подделана.

Выдача JWT

1. Клиент отправляет учетные данные пользователя на сервер аутентификации (универсальный поставщик идентификации особенно полезен для управления доступом через несколько доменов).
2. После успешной аутентификации сервер генерирует JWT, который включает заголовок, полезную нагрузку и подпись.
3. AuthServer отправляет выданный токен на Клиент. Клиент сохраняет JWT (например, в cookies, localStorage или sessionStorage).

Процессы на основе сессий следуют похожему процессу. Однако после аутентификации информация о пользователе сохраняется на сервере внутри сессии, тогда как JWT полагаются на токены, отправленные на клиента для хранения и последующего использования.

Проверка токена

1. Для последующих API-запросов клиент отправляет JWT в заголовке Authorization (Bearer <token>).
2. Сервер проверяет подпись JWT, используя секретный или открытый ключ, и проверяет его претензии (например, срок действия, издатель).
3. Если токен действителен, сервер предоставляет клиенту доступ к запрошенным ресурсам.

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

Как отозвать JWT?#

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

Отзыв JWT (JSON Web Token) более сложен, чем аутентификация на основе сессий, поскольку JWT являются stateless и не могут быть аннулированы после выдачи, если не реализованы конкретные стратегии. Обычные методы включают:

• Короткие сроки действия: Установите короткое значение претензии exp (например, 15 минут) для JWT. Как только срок действия истечет, пользователь должен снова пройти аутентификацию. Это минимизирует риск в случае компрометации токена, поскольку атакующий может его использовать только ограниченное время. Чтобы поддерживать бесшовный пользовательский опыт, обновляющий токен может минимизировать неудобства повторной аутентификации.
• Черный список токенов: В критических случаях (например, выход пользователя, изменения пароля) ведите черный список аннулированных токенов. Сервер проверяет входящие токены на совпадение с этим списком и отклоняет все совпадения. Хотя этот подход эффективен, он требует отслеживания аннулированных токенов, что противоречит stateless природе JWT и может стать неэффективным, если список слишком длинен.
• Конечная точка аннулирования: Введите конечную точку аннулирования на сервере авторизации, где токены (например, обновляющие токены) могут быть аннулированы. Как только обновляющий токен аннулирован, любые токены доступа, выданные с его использованием, более не будут обновляться. Этот метод хорошо работает в потоке OAuth2.

Преимущества аутентификации JWT#

• Быстрее и более информативно: Самодостаточная природа JWT делает проверку на стороне клиента быстрее и более эффективной, без необходимости взаимодействия с сервером. Они также могут включать пользовательские претензии (например, роли пользователей или другие релевантные данные) в токен, что позволяет серверам определять роли без обращения к базе данных.
• Улучшенная безопасность: JWT используют методы подписи и шифрования, затрудняющие атаки.
• Поддержка кросс-домена: JWT идеально подходят для Single Sign-On (SSO) и аутентификации между доменами. Они позволяют пользователям аутентифицироваться в различных доменах или службах, используя один и тот же токен.
• Удобство для мобильных устройств: JWT хорошо работают для мобильных приложений, которым требуется stateless аутентификация. Токены могут храниться на клиентской стороне и отправляться с каждым запросом, повышая эффективность и удобство использования.

Недостатки аутентификации JWT#

• JWT не обновляется в режиме реального времени

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

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

• Дилемма многоустройств и аннулирования

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

Некоторые поставщики удостоверений могут иметь готовые решения для этих проблем JWT. Для получения дополнительной информации ознакомьтесь с "Лучшими практиками для улучшения опыта аутентификации JWT.”

В чем разница между JWT и сессией?#

Сессии и JWT — два популярных подхода для поддержания контекста аутентификации и авторизации в stateless мире HTTP. Хотя оба подхода имеют свои плюсы и минусы, они предлагают различные преимущества и недостатки.

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

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

Поскольку аутентификация на основе токенов более подходит для масштабирования, несмотря на её управляемые недостатки, она принимает всё больше и больше современных приложений.

Сессия против JWT: Выбор правильного метода#

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

Когда использовать аутентификацию на основе сессий#

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

• Веб-приложения с постоянными сессиями

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

• Приложения, требующие контроля сеансов в реальном времени

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

• Системы на одном сервере или в малом масштабе

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

Когда использовать аутентификацию JWT#

JWT аутентификация лучше подходит для приложений, которые придают приоритет масштабируемости, эффективности и распределенности систем. Она особенно полезна для stateless взаимодействий между клиентами и серверами. Рассмотрите возможность использования аутентификации на основе токенов для следующих случаев:

• Single Sign-On (SSO)

  JWT идеально подходят для Single Sign-On, позволяя пользователям аутентифицироваться один раз и бесшовно получать доступ к нескольким сервисам или приложениям с использованием одного и того же токена. Поделитесь подробным объяснением о безопасных облачных приложениях, использующих OAuth 2.0 и OIDC, в формате JWT и для токенов доступа, и для идентификационных токенов.

• Мобильные приложения

  Мобильные приложения часто предпочитают JWT для аутентификации, так как токены могут быть безопасно сохранены на устройстве и отправлены с каждым API-запросом. Исследуйте быструю интеграцию JWT аутентификации для Android / iOS.

• Архитектуры микросервисов

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

• Аутентификация между доменами

  JWT превосходят в сценариях, включающих несколько доменов или поддоменов (например, api.example.com, dashboard.example.com и docs.example.com). В отличие от cookies, JWT позволяют аутентификацию между доменами без дополнительных зависимостей.

• API и веб-сервисы

  RESTful API и веб-сервисы обычно используют JWT для аутентификации, так как они легковесны, портативны и устраняют необходимость в управлении сессиями на стороне сервера. Узнайте больше о автоматизированной аутентификации для сценариев, где ваше приложение должно напрямую общаться с ресурсами.

Лучшие практики для улучшения опыта аутентификации JWT#

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

Решение проблем выхода пользователя из системы с JWT#

Один из распространенных вопросов с аутентификацией JWT это обеспечение надлежащего опыта выхода пользователя из системы. Logto упрощает этот процесс с помощью своего готового SDK.

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

Это обеспечивает консистентное и безопасное управление сессиями в вашей экосистеме. Узнайте больше о механизмах выхода из системы и как реализовать выход.

Обработка изменений в разрешениях пользователя#

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

• При уменьшении разрешений для этого пользователя: Используйте короткие сроки действия токенов доступа или динамически проверяйте разрешения через вызов API.
• Для добавления новых разрешений для этого пользователя: Обновите AuthServer, чтобы включить новую область разрешений, и повторно запросите согласие у пользователей для применения этих изменений.

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

Logto, который является масштабируемой инфраструктурой управления доступом к идентичности, предоставляет полное решение идентификации как облачную услугу, так и open-source версию.