Введение в JWT: JSON Web Token (JWT) — это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в объектах JSON. Эту информацию можно проверить и доверить с помощью цифровых подписей. JWT можно подписывать с помощью секретов (с использованием алгоритма HMAC) или с помощью пар публичных/приватных ключей RSA.
Некоторые сценарии, где JSON Web Tokens полезны:
Проверка личности:Это самый распространённый случай использования JWT. После входа пользователя каждый следующий запрос будет содержать JWT, позволяющий пользователю получать доступ к маршрутам, сервисам и ресурсам, разрешённым этим токеном. Функция единого входа — это функция, широко используемая сегодня благодаря низким накладным расходам и возможности удобного использования в разных областях.
Обмен информацией:JSON Web Tokens — отличный способ безопасной передачи информации между сторонами. Поскольку JWT можно подписывать — например, используя пары публичных/приватных ключей, можно быть уверенным, что отправитель — это тот, за кого он себя выдаёт. Кроме того, поскольку подпись рассчитывается с помощью заголовков и полезных нагрузок, вы также можете проверить, что содержимое не было изменено.
Официальный сайт:Вход по гиперссылке виден.
Разбор информации о JWT онлайн：Вход по гиперссылке виден.
Анализ параметров JWT онлайн Вход по гиперссылке виден.
Моё понимание JWT ниже неверно, пожалуйста, дайте мне совет
Во-первых, эту вещь не рекомендуется использовать на сайте MVC, её можно использовать в webapi, позиционирование этого устройства — это API, а не сессия заменяющего сайта!
asp.net обучающее руководство по использованию webapi:Вход по гиперссылке виден.Я не буду переделывать колесо, смотреть, что написана в этой статье — это нормально.
Состав JWT
JWT состоит из трёх частей: заголовок, полезная нагрузка и подпись, между которыми расположены точечные символы, образующие форму xx.yy.zz.
Обратите внимание, что для подписанных токенов эту информацию может прочитать любой человек, несмотря на защиту от вмешательства. Не размещайте конфиденциальную информацию в корректном содержимом или заголовках JWT, если она не зашифрована.
Например:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
alg: "HS256",
typ: "JWT"
}.
{
sub: "1234567890",
name: "John Doe",
iat: 1516239022
}.
[подпись]
Простым языком, любой может расшифровать этот токен, но подлинность этой информации нельзя проверить, только сервер, который его сгенерировал, может подтвердить подлинность, поэтому не храните в нём конфиденциальную информацию.
Здесь есть проблема: если пользователь меняет пароль или ему запрещено входить, как JWT может проверить валидность токена?
Моя собственная идея — добавить строку, похожую на guid, в раздел Payload, а затем существовать в кэше, при проверке личности пользователя не только проверять jwt, но и информацию о полезной нагрузке в jwt, мы можем контролировать валидность, контролируя кэш.
|
Опубликовано 21.05.2018 15:56:52
|
|
|
|
Хозяин|
Опубликовано 27.04.2021 10:59:48
|
