Что хранится в веб-токенах JSON без сохранения состояния

Question

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

Если я правильно понимаю, проблема с приложениями с состояниемпроисходят, когда мне нужно несколько веб-сервисов (API), по одному для каждого типа устройства, использующего приложение (веб, мобильные и т. д.).Затем веб-службы должны каким-то образом синхронизировать состояния сеанса, что сложно.

Вместо этого мы сохраняем состояние клиента (предпочтительно в файлах cookie) в зашифрованных и подписанных JWT.

Понял ли япока правильно?

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

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

Answer 1

[..] когда мне нужно несколько веб-сервисов (API), по одному для каждого типа устройства, использующего приложение (веб, мобильное и т. Д.).

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

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

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

1. Использовать липкие сеансы, что означает, что веб-серверы сохраняют состояние и хранят информацию о сеансе, а балансировщик нагрузки знает об использованных файлах cookie и перенаправляет трафик с одного и того же клиента на один и тот же сервер, поэтому нужен только один сервердержаться за информацию о сессии.Это делает реализацию сервера относительно простой, но имеет определенные недостатки в работе:

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

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

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

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

   1. Попросить клиента аутентифицировать себя при каждом запросе, то есть отправлять свое имя пользователя и пароль при каждом запросе.Это явно плохая идея, так как вы не хотите постоянно отправлять пароль туда и обратно.Это также потребовало бы запроса к центральной базе данных на сервере каждый раз, что снова подрывает масштабируемость.
   2. Дает пользователю маркер некоторого вида, который аутентифицирует его.Недостатком здесь является то, что требуется общее хранилище токенов, см. №2 выше.

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

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

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