Понимание высокого уровня веб-токенов JSON (JWT) и идентификаторов сеансов.
Недавно я столкнулся с использованием аутентификации с JWT в кодовой базе на работе. Мне было любопытно выяснить разницу в механизме между JWT и стандартными токенами / идентификаторами сеанса, особенно с учетом того, что в последнее время JWT становится все более популярным.
Зачем нам нужна аутентификация?
HTTP - это протокол без сохранения состояния, что просто означает, что текущий запрос клиента не зависит от каких-либо предыдущих запросов, а серверу ничего не известно о каких-либо предыдущих запросах.
Например, если вы просто загружаете статические данные, например, переходите к www.facebook.com, серверам действительно не нужно знать, кто является клиентом, поскольку они возвращают страницу входа в систему, а не конфиденциальная информация в любой форме. С другой стороны, если вы хотите внести изменения в свой профиль Facebook, вам нужно будет доказать, что вы являетесь владельцем учетной записи, прежде чем серверы Facebook вернут вам информацию.
Проще говоря, вам необходимо пройти аутентификацию - подтвердить свою личность - прежде чем сервер сможет предоставить вам доступ к конфиденциальной информации. Чтобы понять необходимость JWT, давайте сделаем шаг назад, чтобы понять текущую модель токена сеанса, которая все еще широко используется.
Аутентификация с помощью токенов сеанса
В модели токена сеанса после того, как пользователь входит в систему и авторизуется, сервер создает сеанс, уникальный для клиента. Сервер возвращает идентификатор сеанса клиенту, который затем сохраняет его в файле cookie в браузере.
При последующих HTTP-вызовах cookie будет автоматически включаться в заголовок HTTP-запроса, и серверы смогут узнать личность клиента. Хотя cookie хранится на стороне клиента, эта модель по-прежнему представляет собой сеансы на стороне сервера, поскольку проверка выполняется на сервере.
Тогда вы можете задаться вопросом - как сервер запоминает личность клиента, если протоколы HTTP не имеют состояния?
Сессия на стороне сервера: на самом деле не без состояния
С технической точки зрения протокол HTTP без сохранения состояния не запрещает серверам хранить информацию. Большинству веб-приложений необходимо сохранять некоторую форму состояния, чтобы знать, действителен ли идентификатор сеанса клиента.
Например, на сервере может быть журнал сеанса (возможно, хэш-таблица или БД), в котором хранится идентификатор сеанса, поэтому всякий раз, когда ранее аутентифицированный клиент делает запрос, сервер может просто найти идентификатор сеанса и убедиться, что клиент аутентифицирован.
Плюсы сессионных токенов
- Срок действия идентификаторов сеансов истек
- Идентификаторы сеанса могут быть отозваны
- Меньший размер cookie (по сути, зашифрованный идентификатор сеанса)
Минусы токенов сеанса
- Масштабируемость - это проблема обеспечения журнала сеанса на всех серверах.
На рисунке выше мы предположили упрощенно-монолитную архитектуру, в которой клиент взаимодействует с одним сервером. Однако в действительности мы можем ожидать полилитическую архитектуру, похожую на следующую:
В некотором смысле эта полилитическая архитектура помогает в определенной степени компенсировать проблемы масштабируемости. Один из способов обеспечить одинаковый журнал сеансов на всех серверах - распределить запросы с помощью балансировщика нагрузки и использовать кеш Redis, общий для всех серверов. Хотя это жизнеспособный обходной путь для обеспечения синхронности журнала сеанса, теперь существует единственная точка отказа (кеш Redis).
Я обсудил только несколько плюсов и минусов, о которых мне удобно говорить, но если вы хотите узнать больше, вы можете прочитать эту статью, в которой обсуждаются сеансы серверные и клиентские.
JSON Web-Token (JWT) Аутентификация
В модели JWT вместо того, чтобы возвращать идентификатор сеанса после входа пользователя в систему, сервер возвращает подписанный токен клиенту. Этот подписанный токен представляет собой объект JSON, содержащий информацию для аутентификации, которая была подписана сервером с использованием секретного или открытого / закрытого ключа.
В последующих HTTP-запросах клиенту просто нужно передать JWT в запросе, и каждый экземпляр сервера имеет возможность расшифровать токен и аутентифицировать пользователя.
Плюсы JWT
- Устраняет необходимость в кэше / базе данных для хранения идентификаторов сеансов
Минусы JWT
- Невозможность отозвать токены с сервера, поскольку они могут только определить, действителен ли токен или нет
Еще раз, я лишь осветил плюсы и минусы JWT, но вы можете проверить эту подробную статью о плюсах и минусах JWT.
Заключительные примечания
Эта статья призвана упростить мое собственное понимание JWT, и я надеюсь, что она помогла вам пролить свет на эти концепции.
Если вы хотите посмотреть визуальные эффекты, я настоятельно рекомендую это видео на YouTube, которое помогло мне быстро понять концепцию.
