Повторная аутентификация
https://stackoverflow.com/questions/319530
-
11-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Что означает RESTful Authentication и как это работает?Я не могу найти хороший обзор в Google.Насколько я понимаю, вы передаете ключ сеанса (remeberal) в URL, но это может быть ужасно неправильно.
Решение
Вопрос о том, как обрабатывать аутентификацию в RESTful клиент-серверной архитектуре, является предметом дискуссий.
Обычно это может быть достигнуто в мире SOA через HTTP с помощью:
- Базовая аутентификация по протоколу HTTP через HTTPS;
- Файлы cookie и управление сеансами;
- Токен в заголовках HTTP (например, OAuth 2.0 + JWT);
- Запросите аутентификацию с дополнительными параметрами подписи.
Вам придется адаптировать или, еще лучше, смешать эти методы, чтобы они в лучшем случае соответствовали архитектуре вашего программного обеспечения.
Каждая схема аутентификации имеет свои плюсы и минусы, в зависимости от цели вашей политики безопасности и архитектуры программного обеспечения.
Базовая аутентификация по протоколу HTTP через HTTPS
Это первое решение, основанное на стандартном протоколе HTTPS, используется большинством веб-сервисов.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Это легко реализовать, доступно по умолчанию во всех браузерах, но имеет некоторые известные недостатки, такие как ужасное окно аутентификации, отображаемое в браузере, которое будет сохраняться (здесь нет функции, подобной выходу из системы), некоторое дополнительное потребление процессора на стороне сервера и тот факт, что имя пользователя и пароль передаются (по HTTPS) на Сервер (было бы безопаснее, если бы пароль оставался только на стороне клиента, во время ввода с клавиатуры, и сохранялся как безопасный хэш на сервере).
Мы можем использовать Дайджест- аутентификация, но для этого требуется также протокол HTTPS, поскольку он уязвим для МиМ или Воспроизведение атаки и специфичны для HTTP.
Сеанс с помощью файлов cookie
Честно говоря, сеанс, управляемый на Сервере, на самом деле не является Апатридом.
Одной из возможностей может быть сохранение всех данных в содержимом файлов cookie.И, по замыслу, файл cookie обрабатывается на стороне Сервера (Клиент, по сути, даже не пытается интерпретировать данные этого файла cookie:он просто передает его обратно серверу при каждом последующем запросе).Но эти данные cookie являются данными о состоянии приложения, поэтому управлять ими должен клиент, а не сервер, в чистом мире без состояния.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
Сам метод использования файлов cookie связан с HTTP, поэтому он на самом деле не является RESTful, который должен быть независимым от протокола, ИМХО.Он уязвим для МиМ или Воспроизведение атаки.
Предоставляется через токен (OAuth2)
Альтернативой является помещение токена в заголовки HTTP, чтобы запрос был аутентифицирован.Это то , что OAuth 2.0, например, так и делает.Видишь RFC 6749:
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Короче говоря, это очень похоже на файл cookie и имеет те же проблемы:не является апатридом, полагается на детали передачи по HTTP и подлежит множество слабых мест в системе безопасности - включая MiM и Replay - so должен использоваться только по протоколу HTTPS.Как правило, a JWT используется в качестве токена.
Проверка подлинности запроса
Аутентификация запроса заключается в подписании каждого RESTful-запроса с помощью некоторых дополнительных параметров в URI.Видишь эта справочная статья.
Как таковое оно было определено в этой статье:
Все запросы REST должны быть аутентифицированы путем подписания параметров запроса отсортированы в нижнем регистре в алфавитном порядке с использованием личных учетных данных в качестве маркера подписи.Подписание должно происходить перед URL, кодирующим строку запроса .
Этот метод, возможно, более совместим с архитектурой без состояния, а также может быть реализован с легким управлением сеансами (используя сеансы в памяти вместо сохранения базы данных).
Например, вот общий пример URI по ссылке выше:
GET /object?apiKey=Qwerty2010
должно передаваться как таковое:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
Подписываемая строка является /object?apikey=Qwerty2010×tamp=1261496500 и подпись - это хэш SHA256 этой строки, использующий закрытый компонент ключа API.
Кэширование данных на стороне сервера всегда может быть доступно.Например, в нашей платформе мы кэшируем ответы на уровне SQL, а не на уровне URI.Таким образом, добавление этого дополнительного параметра не нарушает механизм кэширования.
Видишь эта статья для получения некоторых сведений о проверке подлинности RESTful в нашем клиент-серверном фреймворке ORM / SOA / MVC, основанном на JSON и REST.Поскольку мы разрешаем обмен данными не только по HTTP / 1.1, но и по именованным каналам или сообщениям GDI (локально), мы попытались реализовать действительно RESTful шаблон аутентификации, а не полагаться на специфику HTTP (например, заголовок или файлы cookie).
Более Позднее Примечание:добавление подписи в URI может рассматриваться как плохая практика (поскольку, например, она будет отображаться в журналах http-сервера), поэтому ее необходимо смягчить, напримерс помощью правильного TTL, чтобы избежать повторов.Но если ваши http-журналы будут скомпрометированы, у вас наверняка возникнут более серьезные проблемы с безопасностью.
На практике предстоящий Аутентификация токенов MAC для OAuth 2.0 это может быть огромным улучшением по сравнению с текущей схемой "Предоставлено токеном".Но это все еще незавершенная работа, и она привязана к передаче по HTTP.
Заключение
Стоит сделать вывод, что REST основан не только на HTTP, даже если на практике он также в основном реализуется через HTTP.REST может использовать другие уровни связи.Таким образом, аутентификация RESTful - это не просто синоним HTTP-аутентификации, что бы ни отвечал Google.Он даже не должен вообще использовать механизм HTTP, но должен быть абстрагирован от уровня связи.И если вы используете HTTP-связь, благодаря Давайте зашифруем инициативу нет никаких причин не использовать надлежащий протокол HTTPS, который требуется в дополнение к любой схеме аутентификации.
Другие советы
Я сомневаюсь, что люди, с энтузиазмом кричащие "HTTP-аутентификация", когда-либо пытались создать браузерное приложение (вместо межмашинного веб-сервиса) с помощью REST (без обид - я просто не думаю, что они когда-либо сталкивались с осложнениями).
Проблемы, которые я обнаружил при использовании HTTP-аутентификации в службах RESTful, которые создают HTML-страницы для просмотра в браузере, заключаются в следующем:
- пользователь обычно получает уродливое окно входа в систему, созданное браузером, которое очень недружелюбно к пользователю.вы не можете добавить поиск пароля, поля справки и так далее.
- выход из системы или вход в систему под другим именем является проблемой - браузеры будут продолжать отправлять аутентификационную информацию на сайт до тех пор, пока вы не закроете окно
- тайм-ауты - это сложно
Очень содержательная статья, в которой эти вопросы рассматриваются пункт за пунктом, такова здесь, но это приводит к лот о взломе JavaScript для конкретного браузера, обходных путях для обходных путей и так далее.Как таковой, он также не совместим с прямой передачей, поэтому будет требовать постоянного обслуживания по мере выпуска новых браузеров.Я не считаю этот чистый и понятный дизайн, плюс я чувствую, что это большая дополнительная работа и головная боль только для того, чтобы я мог с энтузиазмом показывать свой значок ОТДЫХА своим друзьям.
Я считаю, что файлы cookie - это решение проблемы.Но подождите, печенье - это зло, не так ли?Нет, это не так, способ, которым часто используются файлы cookie, является злом.Сам файл cookie - это всего лишь фрагмент информации на стороне клиента, точно так же, как информация об аутентификации HTTP, которую браузер будет отслеживать во время вашего просмотра.И эта часть клиентской информации отправляется на сервер при каждом запросе, опять же точно так же, как и информация об аутентификации HTTP.Концептуально единственное отличие заключается в том, что Содержание часть этого состояния на стороне клиента может быть определена с помощью сервер как часть его ответа.
Сделав сеансы ресурсом RESTful только со следующими правилами:
- A сессия сопоставляет ключ с идентификатором пользователя (и, возможно, с отметкой времени последнего действия для тайм-аутов)
- Если a сессия существует, тогда это означает, что ключ действителен.
- Вход в систему означает публикацию в / sessions, новый ключ устанавливается в виде файла cookie
- Выход из системы означает удаление /sessions/{key} (помните, что с перегруженным POST мы являемся браузером, а до HTML 5 еще далеко)
- Аутентификация осуществляется путем отправки ключа в виде файла cookie при каждом запросе и проверки того, существует ли сеанс и является ли он действительным
Единственное отличие от HTTP-аутентификации теперь заключается в том, что ключ аутентификации генерируется сервером и отправляется клиенту, который продолжает отправлять его обратно, вместо того, чтобы клиент вычислял его на основе введенных учетных данных.
converter42 добавляет, что при использовании https (что мы и должны делать) важно, чтобы у файла cookie был установлен флаг защищенности, чтобы информация об аутентификации никогда не отправлялась по незащищенному соединению.Отличный момент, сам этого не видел.
Я чувствую, что это достаточное решение, которое работает нормально, но я должен признать, что я недостаточно эксперт по безопасности, чтобы выявить потенциальные дыры в этой схеме - все, что я знаю, это то, что сотни веб-приложений, не поддерживающих RESTful, используют по существу один и тот же протокол входа ($ _SESSION в PHP, HttpSession в Java EE и т.д.).Содержимое заголовка cookie просто используется для обращения к ресурсу на стороне сервера, точно так же, как язык принятия может использоваться для доступа к ресурсам перевода и так далее.Я чувствую, что это то же самое, но, может быть, другие этого не делают?Что вы думаете, ребята?
Здесь хорошими людьми уже достаточно сказано на эту тему.Но вот мои 2 цента.
Существует 2 способа взаимодействия:
- взаимодействие человека с машиной (HTM)
- межмашинный переход (MTM)
Машина - это общий знаменатель, выраженный в виде REST API, а действующими лицами / клиентами являются либо люди, либо машины.
Теперь, в действительно RESTful архитектуре, концепция безгражданства подразумевает, что все соответствующие состояния приложения (имеются в виду состояния на стороне клиента) должны предоставляться с каждым запросом.Под релевантным подразумевается все, что требуется REST API для обработки запроса и предоставления соответствующего ответа.
Когда мы рассматриваем это в контексте человеко-машинных приложений, "браузерных", как указывает Скреббел выше, это означает, что (веб) приложение, запущенное в браузере, должно будет отправлять свое состояние и соответствующую информацию с каждым запросом, который оно делает, в серверные REST API.
Подумайте об этом:У вас есть открытый ресурс REST API для платформы данных / информации.Возможно, у вас есть BI-платформа самообслуживания, которая обрабатывает все кубы данных.Но вы хотите, чтобы ваши клиенты (люди) получали доступ к этому через (1) веб-приложение, (2) мобильное приложение и (3) какое-либо стороннее приложение.В конце концов, четная цепочка MTM приводит к HTM - right.Таким образом, пользователи-люди остаются на вершине информационной цепочки.
В первых 2 случаях у вас есть случай взаимодействия человека с машиной, когда информация фактически потребляется пользователем-человеком.В последнем случае у вас есть машинная программа, использующая REST API.
Концепция аутентификации применима ко всем направлениям.Как вы будете это проектировать, чтобы доступ к вашим REST API был единообразным и защищенным?На мой взгляд, есть 2 способа:
Способ-1:
- Начнем с того, что здесь нет логина.Каждый запрос выполняет вход в систему
- Клиент отправляет свои идентификационные параметры + специфические для запроса параметры с каждым запросом
- REST API принимает их, разворачивается, выполняет пинг в пользовательском хранилище (что бы это ни было) и подтверждает аутентификацию
- Если аутентификация установлена, обрабатывает запрос;в противном случае отклоняется с соответствующим кодом состояния HTTP
- Повторите выше для каждого запроса во все остальные API в вашем каталог
Способ-2:
- Клиент начинает с запроса авторизации
- REST API для входа в систему будет обрабатывать все такие запросы
- Он принимает параметры аутентификации (ключ API, uid / pwd или что бы вы ни выбрали ) и проверяет аутентификацию в пользовательском хранилище (LDAP, AD или MySQL DB и т.д.)
- В случае подтверждения создает токен авторизации и передает его обратно клиенту /вызывающему
- Затем вызывающий объект отправляет этот токен авторизации + запрашивает конкретные параметры с каждым последующим запросом к другим бизнес-REST API, пока не выйдет из системы или пока не истечет срок аренды
Очевидно, что в Way-2 API REST потребуется способ распознавания токена и доверия ему как действительному.API входа в систему выполнил проверку подлинности, и поэтому этому "ключу valet" должны доверять другие REST API в вашем каталоге.
Это, конечно, означает, что ключ аутентификации / токен необходимо будет сохранить и совместно использовать среди REST API.Это общее, доверенное хранилище токенов может быть любым локальным / федеративным, что позволяет REST API из других организаций доверять друг другу.
Но я отвлекся.
Дело в том, что "состояние" (о статусе аутентификации клиента) необходимо поддерживать и совместно использовать, чтобы все REST API могли создавать круг доверия.Если мы этого не сделаем, а это Способ-1, мы должны согласиться с тем, что акт аутентификации должен быть выполнен для любых / всех поступающих запросов.
Выполнение аутентификации - это ресурсоемкий процесс.Представьте, что вы выполняете SQL-запросы для каждого входящего запроса к вашему хранилищу пользователей, чтобы проверить соответствие uid / pwd.Или для шифрования и выполнения сопоставления хэшей (в стиле AWS).И я подозреваю, что с архитектурной точки зрения каждый REST API должен будет выполнять это, используя общую серверную службу входа в систему.Потому что, если вы этого не сделаете, то вы разбросаете код аутентификации повсюду.Большой беспорядок.
Таким образом, чем больше слоев, тем больше задержка.
Теперь возьмите Способ-1 и применитесь к HTM.Действительно ли вашего (человека) пользователя волнует, нужно ли отправлять uid / pwd / hash или что-то еще с каждым запросом?Нет, до тех пор, пока вы не будете беспокоить ее, ежесекундно открывая страницу авторизации.Удачи вам в привлечении клиентов, если вы это сделаете.Итак, что вы сделаете, так это сохраните регистрационную информацию где-нибудь на стороне клиента, в браузере, в самом начале, и отправляйте ее с каждым сделанным запросом.Для пользователя (человека) она уже вошла в систему, и доступен "сеанс".Но на самом деле она проходит проверку подлинности по каждому запросу.
То же самое и с Способом-2.Ваш пользователь (человек) никогда этого не заметит.Так что никакого вреда причинено не было.
Что, если мы применим Способ-1 к MTM?В этом случае, поскольку это машина, мы можем до чертиков надоесть этому парню, прося его отправлять аутентификационную информацию при каждом запросе.Всем наплевать!Выполнение Way-2 на MTM не вызовет никакой особой реакции;это чертова машина.Это могло бы волновать меньше!
Так что на самом деле вопрос в том, что соответствует вашим потребностям.За безгражданство приходится платить.Заплати цену и двигайся дальше.Если вы хотите быть пуристом, то заплатите цену и за это, и двигайтесь дальше.
В конце концов, философия не имеет значения.Что действительно важно, так это поиск информации, ее представление и опыт потребления.Если людям нравятся ваши API, значит, вы выполнили свою работу.
Вот действительно и полностью RESTful решение для аутентификации:
- Создайте пару открытых / закрытых ключей на сервере аутентификации.
- Распространите открытый ключ по всем серверам.
Когда клиент проходит аутентификацию:
3.1.выдайте токен, который содержит следующее:
- Срок годности
- имя пользователя (необязательно)
- IP-адрес пользователя (необязательно)
- хэш пароля (необязательно)
3.2.Зашифруйте токен с помощью закрытого ключа.
3.3.Отправьте зашифрованный токен обратно пользователю.
Когда пользователь обращается к какому-либо API, он также должен передать свой токен аутентификации.
- Серверы могут проверить, что токен действителен, расшифровав его с помощью открытого ключа сервера аутентификации.
Это аутентификация без сохранения состояния / RESTful.
Обратите внимание, что если бы хэш пароля был включен, пользователь также отправил бы незашифрованный пароль вместе с маркером аутентификации.Сервер может проверить, что пароль соответствует паролю, который был использован для создания токена аутентификации, путем сравнения хэшей.Было бы необходимо безопасное соединение, использующее что-то вроде HTTPS.Javascript на стороне клиента может обрабатывать получение пароля пользователя и сохранять его на стороне клиента либо в памяти, либо в файле cookie, возможно, зашифрованном с помощью сервера публичный Клавиша.
Если честно, я видел здесь отличные ответы, но меня немного беспокоит то, что кто-то доведет всю концепцию безгражданства до крайности, когда она станет догматичной. Это напоминает мне о тех старых фанатах Smalltalk, которые хотели только принять чистый ОО, и если что-то не является объектом, то вы делаете это неправильно. Дай мне перерыв.
Подход RESTful, как предполагается, облегчит вашу жизнь и сократит накладные расходы и затраты на занятия, постарайтесь следовать им, поскольку это разумно, но в ту минуту, когда вы следуете дисциплине (любой дисциплине / руководству) для крайность, когда она больше не дает той выгоды, для которой она предназначена, тогда вы делаете это неправильно. Некоторые из лучших современных языков имеют функциональное программирование и объектную ориентацию.
Если вам проще всего решить вашу проблему, это сохранить ключ аутентификации в файле cookie и отправить его в заголовке HTTP, а затем просто не злоупотребляйте им. Помните, что сессии плохие, когда они становятся тяжелыми и большими, если весь ваш сеанс состоит из короткой строки, содержащей ключ, то в чем же дело?
Я открыт для принятия исправлений в комментариях, но я просто не вижу смысла (пока) в том, чтобы сделать нашу жизнь несчастной, чтобы просто не хранить большой словарь хэшей на нашем сервере.
Прежде всего, веб-сервис RESTful является STATELESS (или, другими словами, SESSIONLESS ). Следовательно, сервис RESTful не имеет и не должен иметь понятия сеанса или файлов cookie. Способ выполнения аутентификации или авторизации в службе RESTful заключается в использовании заголовка авторизации HTTP, как определено в спецификациях HTTP RFC 2616. Каждый отдельный запрос должен содержать заголовок авторизации HTTP, а запрос должен отправляться через соединение HTTP (SSL). Это правильный способ проверки подлинности и проверки авторизации запросов в веб-службах HTTP RESTful. Я реализовал веб-сервис RESTful для приложения Cisco PRIME Performance Manager в Cisco Systems. И как часть этого веб-сервиса, я также реализовал аутентификацию / авторизацию.
Рубенс Гомес.
Речь, конечно же, не о «ключах сеанса». как это обычно используется для ссылки на бессессионную аутентификацию, которая выполняется в рамках всех ограничений REST. Каждый запрос имеет самоописание и содержит достаточно информации для самостоятельной авторизации запроса без какого-либо состояния приложения на стороне сервера.
Самый простой способ добиться этого - начать со встроенных механизмов HTTP-аутентификации в RFC 2617 .
«Очень проницательная» статья, упомянутая @skrebel ( http://www.berenddeboer.net /rest/authentication.html ) обсуждается запутанный, но действительно сломанный метод аутентификации.
Вы можете попытаться посетить страницу (которая должна быть доступна для просмотра только авторизованному пользователю) http://www.berenddeboer.net/rest/site/authenticated.html без каких-либо учетных данных для входа.
(Извините, я не могу комментировать ответ.)
Я бы сказал, REST и аутентификация просто не смешиваются. REST означает безгражданство, но «заверенный» - это состояние. Вы не можете иметь их обоих на одном слое. Если вы являетесь защитником RESTful и недовольны состояниями, то вам нужно использовать HTTPS (т.е. оставить проблему безопасности на другом уровне).
Я думаю, что спокойная аутентификация включает передачу токена аутентификации в качестве параметра в запросе. Примерами являются использование apikeys от api. Я не верю, что использование cookie-файлов или http-аутентификации оправдано.
Обновление от 16 февраля 2019 года
Подход, упомянутый ранее ниже, по существу является «учетными данными для пароля владельца ресурса». тип предоставления OAuth2.0 . Это простой способ начать работу. Однако при таком подходе каждое приложение в организации будет иметь собственные механизмы аутентификации и авторизации. Рекомендуемый подход - «Код авторизации». тип предоставления. Кроме того, в моем предыдущем ответе ниже я рекомендовал браузер localStorage для хранения токенов авторизации. Тем не менее, я пришел к выводу, что cookie является правильным вариантом для этой цели. Я подробно изложил свои причины, подход к реализации типа предоставления кода авторизации, соображения безопасности и т. Д. В этом ответе StackOverflow .
<Ч>Я думаю, что для аутентификации службы REST можно использовать следующий подход:
<Ол>При таком подходе мы выполняем дорогостоящую операцию загрузки кеша с конкретными правами доступа пользователя каждые 30 минут. Таким образом, если доступ отменен или новый доступ предоставлен, для его отражения требуется 30 минут или выхода из системы, после чего следует вход в систему.
Это способ сделать это: Использование OAuth 2.0 для входа в систему .
Вы можете использовать другие методы аутентификации, отличные от Google, если они поддерживают OAuth.
Чтобы ответить на этот вопрос из моего понимания ...
Система аутентификации, которая использует REST, так что вам не нужно фактически отслеживать или управлять пользователями в вашей системе. Это делается с помощью HTTP-методов POST, GET, PUT, DELETE. Мы берем эти 4 метода и рассматриваем их с точки зрения взаимодействия с базой данных как CREATE, READ, UPDATE, DELETE (но в Интернете мы используем POST и GET, потому что это то, что сейчас поддерживают якорные теги). Таким образом, рассматривая POST и GET как наши CREATE / READ / UPDATE / DELETE (CRUD), мы можем разработать маршруты в нашем веб-приложении, которые смогут определить, какое действие CRUD мы достигаем.
Например, в приложении Ruby on Rails мы можем создать наше веб-приложение таким образом, чтобы, если пользователь, вошедший в систему, посещал http://store.com/account/logout , тогда GET этой страницы можно просмотреть как пользователя, пытающегося выйти из системы. В нашем контроллере rails мы создали бы действие, которое выводит пользователя из системы и отправляет его обратно на домашнюю страницу.
GET на странице входа даст форму. POST на странице входа в систему будет рассматриваться как попытка входа в систему, при этом данные POST будут использоваться для входа в систему.
Для меня это практика использования методов HTTP, сопоставленных с их значением в базе данных, а затем создание системы аутентификации с учетом того, что вам не нужно передавать какие-либо идентификаторы сеансов или отслеживать сеансы.
Я все еще учусь - если вы обнаружите, что я сказал что-то неправильно, поправьте меня, и если вы узнаете больше, опубликуйте это здесь. Спасибо.
Использование инфраструктуры открытого ключа, в которой регистрация ключа включает в себя надлежащее связывание, гарантирует, что открытый ключ будет привязан к индивидууму, которому он назначен, таким образом, что обеспечивается отказ от авторства
См. http://en.wikipedia.org/wiki/Public_key_infrastructure . Если вы соблюдаете надлежащие стандарты PKI, лицо или агент, который неправильно использует украденный ключ, может быть идентифицирован и заблокирован. Если агенту требуется использовать сертификат, привязка становится довольно жесткой. Умный и быстроходный вор может сбежать, но они оставляют больше крошек.
Советы действительны для защиты любого веб-приложения
Если вы хотите защитить свое приложение, , вам определенно следует начать использовать HTTPS вместо HTTP , это обеспечит создание безопасного канала между вами & amp; пользователи, которые будут препятствовать прослушиванию данных, отправленных обратно & amp; вперед пользователям & amp; поможет сохранить конфиденциальность обмена данными.
Вы можете использовать JWT (JSON Web Tokens) для защиты API RESTful . Это дает много преимуществ по сравнению с сеансами на стороне сервера, в основном это следующие преимущества:
1 - Более масштабируемый, так как ваши серверы API не должны будут поддерживать сеансы для каждого пользователя (что может быть большим бременем, когда у вас много сеансов)
2- JWT являются автономными & amp; есть утверждения, которые определяют роль пользователя, например & amp; что он может получить доступ & amp; выпущен на дату & amp; срок действия (после которого JWT не будет действителен)
3- Легче работать с балансировщиками нагрузки и если у вас есть несколько серверов API, так как вам не нужно обмениваться данными сеанса и не настраивать сервер для маршрутизации сеанса на один и тот же сервер, каждый раз, когда запрос с JWT попадает на любой сервер, он может быть аутентифицирован & amp; разрешено
4- Меньшая нагрузка на вашу БД, а также вам не придется постоянно хранить & amp; получить идентификатор сеанса & amp; данные для каждого запроса
5 - JWT не могут быть подделаны, если вы используете сильную клавишу для подписи JWT, поэтому вы можете доверять утверждениям в JWT, отправляемом с запросом, без необходимости проверять сеанс пользователя & amp; авторизован он или нет, вы можете просто проверить JWT & amp; тогда вы все знаете, кто & amp; что может сделать этот пользователь.
Многие библиотеки предоставляют простые способы создания & amp; проверить JWT на большинстве языков программирования, например: в node.js одним из самых популярных является jsonwebtoken
Поскольку REST API, как правило, нацелены на то, чтобы сервер не сохранял состояние, поэтому JWT более совместимы с этой концепцией , поскольку каждый запрос отправляется с токеном авторизации, который является автономным (JWT) сервер не должен отслеживать сеанс пользователя по сравнению с сеансами, которые делают сервер настроенным так, чтобы он запоминал пользователя & amp; его роль, однако, сессии также широко используются & amp; есть свои плюсы, которые вы можете искать, если хотите.
Важно отметить, что вам необходимо безопасно доставить JWT клиенту, используя HTTPS & amp; сохраните его в надежном месте (например, в локальном хранилище).
Подробнее о JWT можно узнать по этой ссылке
