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

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

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

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

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

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

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

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

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

Валидация сессии

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

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

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

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

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

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

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

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

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

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

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

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

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

Выпуск JWT

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

В प्रक्रे аутентификации на основе сессии следует аналогичный процесс. Однако после аутентификации информация о пользователе сохраняется на сервере в рамках сессии, тогда как JWT полагаются на токены, отправляемые клиенту для хранения и последующего использования.

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

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

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

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

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

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

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

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

• Быстрее и информативнее: Самодостаточность JWT делает клиентскую верификацию быстрее и эффективнее, без необходимости в серверном взаимодействии. Они также могут включать пользовательские претензии (например, роли пользователей или другие релевантные данные) внутри токена, позволяя серверам определять роли без запроса к базе данных.
• Улучшенная безопасность: JWT используют технологии подписи и шифрования, что затрудняет атаки.
• Поддержка междоменного доступа: JWT идеально подходят для единого входа (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 взаимодействий между клиентами и серверами. Обратите внимание на аутентификацию на основе токенов для следующих случаев:

• Единый вход (SSO)

  JWT идеально подходят для единого входа (SSO), позволяя пользователям аутентифицироваться один раз и беспрепятственно получать доступ к нескольким сервисам или приложениям с использованием того же токена. Делитесь подробные объяснения по безопасным облачным приложениям с использованием OAuth 2.0 и OIDC, с форматом JWT как для токенов доступа, так и для ID токенов.

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

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

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

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

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

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

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

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

Рекомендации по улучшению опыта аутентификации JWT#

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

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

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

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

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

Обработка изменений прав доступа пользователей#

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

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

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

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