Вступ до 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
|
