О: Обычно хранится в клиенте.
jwt — это веб-токен JSON, протокол аутентификации, который обычно используется для проверки запрошенной идентификационной информации и разрешений на идентификацию.
Когда я утром ходил по магазинам, я встретил одноклассника, который задавал этот вопрос и очень интересовался местом хранения jwt. Я только что изучал этот контент некоторое время назад, пожалуйста, не приглашайте себя и отвечайте с нахальным лицом.
Сначала мне тоже было любопытно, как сохранить этот токен, и я почти хотел использовать Redis для хранения этого токена.
Позже, ознакомившись с информацией, я узнал, что этот токен не может быть сохранен сервером. Вам нужно только сохранить клиент, каким бы способом он ни хранился, даже если вы позволите пользователю написать заметку и положить ее в карман!
Так как же работает этот токен?
Сначала поговорим об операциях, требующих хранения на стороне сервера, то есть традиционном сеансе сеанса.
Прежде всего, чтобы выполнить вход пользователя, вы должны сначала поддерживать таблицу входа на стороне сервера.Эта таблица входа может быть помещена в кеш или в базу данных.
Когда пользователь входит в систему, информация о пользователе записывается в таблицу входа, а затем экспортируется идентификатор входа, который является так называемой сессией, и сессия возвращается клиенту, чтобы клиент мог передать эту информацию. к следующему запросу.
Для фронтенд-приятелей этот процесс обычно не осознается, а бэкенд-приятели используют
set-cookieПоле заголовка http, и данные записываются в файл cookie браузера сами по себе. Затем, когда запрос будет сделан, браузер сам запишет cookie в заголовок запроса.
Когда клиент запрашивает вход на сервер, сервер получает сеанс в файле cookie, а затем переходит к таблице входа, чтобы проверить информацию о пользователе, проверить разрешения пользователя, а затем завершить обычное деловое взаимодействие.
Эй, теперь я не хочу поддерживать таблицу входа в систему по разным причинам, что мне делать?
Это просто, отправьте информацию о пользователе непосредственно клиенту и позвольте клиенту каждый раз приносить информацию о пользователе, чтобы после поступления запроса вам даже не нужно было проверять таблицу, вы могли напрямую узнать, какой пользователь запрашивает .
Но таким образом раскрывается информация о пользователе.Такой прямолинейный запрос больше всего нравится тем посредникам.Они прямо берут табуретку и садятся на порт вашего сервера.Просидев несколько дней,старая таблица всей семьи в вашем база данных будет сорвана другими.
Это определенно невозможно, так что мне делать?
Добавьте пароль, а затем перепутайте его, чтобы старые приятели получили ваш токен, и они на какое-то время будут в замешательстве, и есть большая вероятность, что они уйдут по невнимательности, оставив лишь небольшое количество старых приятелей, которые приходят с готовность (KPI) Упорный поиск решения.
Как только вы расшифруете его на сервере, вы получите информацию о пользователе.Точно так же вы также запишете время истечения срока действия в зашифрованный текст, и если он истечет, он перейдет на страницу входа с 401. Таким образом, выпускается решение, которое не требует внутреннего хранения учетных данных для входа.
Это самый основной принцип работы jwt: передача идентификационной информации клиенту на хранение.
Токен, сгенерированный jwt, состоит из заголовка, полезной нагрузки и подписи, разделенных десятичной точкой «.».
- Заголовок, то есть информация заголовка — это основная информация, описывающая токен, которая находится в формате json:
{ "alg":"HS256", "typ":"JWT" }algПредставляет собой алгоритм шифрования генерации подписной части подписи позже,typУказывает, что токен имеет тип jwt. - Полезная нагрузка, то есть ваши пользовательские данные, также находится в формате json. Однако jwt не рекомендует помещать в него конфиденциальные данные, потому что в спецификации полезная нагрузка совпадает с заголовком, и она отображается на токене только после кодировки base64.
- Подпись — это подпись токена. Обычно это строка, сгенерированная путем шифрования предыдущего заголовка и полезной нагрузки с помощью строки закрытого ключа, которую вы определяете самостоятельно.
Поскольку, как упоминалось ранее, jwt только base64 кодирует содержимое полезной нагрузки, поэтому злоумышленникам все еще очень просто изменить ваш контент, но старые приятели не знают ваш закрытый ключ, вы не можете его сгенерировать после его изменения. .Правильная подпись используется для проверки входящего заголовка.полезной нагрузки запроса еще раз в зашифрованном виде, и обнаруживается, что он не соответствует подписи.В это время вы можете четко знать, что кто-то что-то делает, и напрямую вернуть 500, делая вид, что сервер не работает.
Если вы хотите быть более безопасным, рекомендуется использовать протокол https для передачи запросов.
Конечно, если вы уже понимаете принцип работы, то не невозможно самому создать набор отвратительных спецификаций, например, заново зашифровать полезную нагрузку, а затем сжать ее и так далее.
Итак, каковы преимущества использования jwt?
Первый момент заключается в том, что серверу не нужно вести таблицу входа в систему, что экономит место, особенно при большом количестве пользователей.
Второй момент заключается в том, что расширение простое: вы ничего не делаете и честно соблюдаете формат json для выражения своего контента.
Третий пункт — stateless.Пока сервер поддерживает парсинг, бизнес можно вести.Нет необходимости создавать специальный механизм для обмена сессиями, что удобно для добавления машин.
Четвертый момент заключается в том, что он поддерживает различные клиенты и может играть без файлов cookie.
Недостатком, конечно же, является то, что каждый запрос должен приносить с собой эти данные, что определенно увеличивает содержание запроса. Более того, каждый раз, когда приходит запрос, вы должны его верифицировать.Чтобы зашифровать и проверить подпись с заголовком и полезной нагрузкой, это также увеличит время обработки запроса. По сравнению с традиционными операциями это фактически компромисс между временем и пространством.В конце концов, выбор за вами.