Въведение в JWT: JSON Web Token (JWT) е отворен стандарт (RFC 7519), който дефинира компактен и самостоятелен начин за сигурен трансфер на информация между страни в JSON обекти. Тази информация може да бъде проверена и доверена чрез цифрови подписи. JWT могат да бъдат подписани чрез тайни (чрез алгоритъма HMAC) или чрез публични/частни ключове на RSA.
Някои сценарии, в които JSON уеб токените са полезни:
Проверка на самоличността:Това е най-честият случай на използване на JWT. След като потребителят влезе, всяка следваща заявка ще съдържа JWT, който позволява на потребителя да достъпва маршрутите, услугите и ресурсите, разрешени от този токен. Единичното влизане е функция, която се използва широко днес поради ниските си разходи и възможността да се използва лесно в различни области.
Обмен на информация:JSON уеб токените са отличен начин за сигурен трансфер на информация между страните. Тъй като 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 ч.
|
