П'ять простих кроків для розуміння JSON Web Tokens (JWT)

Представляю вам мій досить вільний переклад статті 5 Easy Steps to Understanding JSON Web Tokens (JWT). JSON Web Tokens (JWT) і з чим їх їдять. Тобто, яку роль вони грають у перевірці справжності користувача та забезпеченні безпеки даних програми.
Спочатку розглянемо формальне визначення.

JSON Web Token (JWT) - це JSON об'єкт, який визначено у відкритому стандарті RFC 7519. Він вважається одним з безпечних способів передачі інформації між двома учасниками. і т.д. та підписи (signature).
До речі, правильно JWT вимовляється як /dʒɒt/

Простими словами, JWT - Це лише рядок у наступному форматі header.payload.signature.
Припустимо, що ми хочемо зареєструватися на сайті. У нашому випадку є три учасники - користувач user , сервер application server і сервер автентифікації authentication server .

1. Спочатку користувач заходить на сервер аутентифікації за допомогою аутентифікаційного ключа (це може бути пара логін/пароль, або Facebook ключ, або Google ключ, або ключ від іншого обліку).
2. Потім сервер автентифікації створює JWT та відправляє його користувачеві.
3. Коли користувач робить запит до програми API, він додає до нього отриманий раніше JWT.
4. Коли користувач робить API запит, програма може перевірити за переданим із запитом JWT Чи є користувач тим, за кого себе видає. У цій схемі сервер програми налаштований так, що зможе перевірити, чи є вхідний. JWT саме тим, що було створено сервером аутентифікації (процес перевірки буде пояснено пізніше детальніше).

Структура JWT

JWT складається з трьох частин: заголовок header , корисні дані payload і підпис signature .

Крок 1. Створюємо HEADER

Хедер JWT містить інформацію про те, як має обчислюватися JWT підпис. JSON об'єкт, який виглядає так:

Поле typ не каже нам нічого нового, тільки те, що це JSON Web Token.. Цікавіше тут буде поле alg, яке визначає алгоритм хешування. використовуватись інший алгоритм RS256 — на відміну від попереднього, він є асиметричним і створює два ключі: публічний і приватний. За допомогою приватного ключа створюється підпис, а за допомогою публічного лише перевіряється справжність підпису, тому нам не потрібно турбуватися про його безпеку.

Крок 2. Створюємо PAYLOAD

Payload - Це корисні дані, які зберігаються всередині JWT. Ці дані також називають JWT-claims (Заявки) У прикладі, який ми розглядаємо, сервер аутентифікації створює. JWT з інформацією про id користувача - userId.

Ми поклали лише одну заявку (claim) у payload. Ви можете покласти стільки. заявокскільки захочете.Існує список стандартних заявок для JWT payload - ось деякі з них:

• iss (issuer) - Визначає додаток, з якого відправляється токен.
• sub (subject) - Визначає тему токена.
• exp (Expiration time) - час життя токена.

Ці поля можуть бути корисними під час створення JWTале вони не є обов'язковими. Якщо хочете знати весь список доступних полів для JWT, можете заглянути у Wiki. Але варто пам'ятати, що чим більше передається інформації, тим більший вийде сам. JWT. Зазвичай із цим не буває проблем, але все-таки це може негативно позначитися на продуктивності та викликати затримки у взаємодії із сервером.

Крок 3. Створюємо SIGNATURE

Підпис обчислюється з використанням наступного псевдо-коду:

const SECRET_KEY = 'cAtwa1kkEy' const unsignedToken = base64urlEncode(header) + '.' + base64urlEncode(payload) const signature = HMAC-SHA256(unsignedToken, SECRET_KEY)

Алгоритм base64url кодує хедер та payload, створені на 1 і 2 кроку. Алгоритм з'єднує закодовані рядки через точку. Потім отриманий рядок хешується алгоритмом, заданим у хедері на основі нашого секретного ключа.

// header eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 // payload eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjY -xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Крок 4. Тепер об'єднаємо всі три JWT компоненти разом

Тепер, коли у нас є всі три складові, ми можемо створити наш JWT. Це досить просто, ми поєднуємо всі отримані елементи в рядок через точку.

const token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature) // JWT Token // eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4 ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Ви можете спробувати створити свій власний JWT на сайті jwt.io.
Повернемося до нашого прикладу. Тепер сервер автентифікації може надсилати користувачеві JWT.

Як JWT захищає наші дані?

Дуже важливо розуміти, що використання JWT НЕ приховує та не маскує дані автоматично. Причина, чому JWT використовуються - це перевірка, що надіслані дані були дійсно відправлені авторизованим джерелом. Як було продемонстровано вище, дані всередині JWT закодовані та підписані, зверніть увагу, це не одне й те, що зашифровані. Мета кодування даних – перетворення структури. Підписані дані дозволяють одержувачу даних перевірити автентифікацію джерела даних. Таким чином закодування та підпис даних не захищає їх. З іншого боку, головною метою шифрування є захист даних від неавторизованого доступу. Для більш детального пояснення різниці між кодуванням та шифруванням, а також про те, як працює хешування, дивіться цю статтю. Оскільки JWT тільки закодована і підписана, і оскільки JWT не зашифрована, JWT не гарантує жодної безпеки для чутливих (sensitive) даних.

Крок 5. Перевірка JWT

У нашому простому прикладі з 3 учасників ми використовуємо JWT, який підписаний за допомогою алгоритму HS256 і тільки сервер аутентифікації та сервер додатка знають секретний ключ.Сервер програми отримує секретний ключ від сервера автентифікації під час встановлення автентифікаційних процесів. Оскільки програма знає секретний ключ, коли користувач робить API-запит з прикладеним до нього токеном, програма може виконати той же алгоритм підписування до JWT, що за крок 3. Додаток може потім перевірити цей підпис, порівнюючи його зі своїм власним, обчисленим хешуванням. Якщо підписи збігаються, значить JWT валідний, тобто. прийшов від перевіреного джерела. Якщо підписи не збігаються, то щось пішло не так — можливо, це є ознакою потенційної атаки. Таким чином, перевіряючи JWT, додаток додає довірчий шар (a layer of trust) між собою та користувачем.

На закінчення

Ми пройшлися тим, що таке JWT, як вони створюються і як валідуються, яким чином вони можуть бути використані для встановлення довірчих відносин між користувачем та додатком. Але це лише шматочок пазла великої теми авторизації та забезпечення захисту вашої програми. Ми розглянули лише основи, але без них неможливо рухатись далі.

Що далі?

Подумаємо про безпеку та додамо Refresh Token. Дивіться наступну статтю на цю тему.

Корисні посилання

Токен авторизації на прикладі JSON WEB Token

https://proglib.io/p/jwt-for-dummies/ Доброго часу доби, дорогий читачу. У цій статті я постараюся розповісти про один із найпопулярніших (на сьогоднішній день) способів авторизації в різних клієнт-серверних додатках - токен авторизації. А розглядати ми його будемо на прикладі найпопулярнішої реалізації – JSON Web Token чи JWT.

Вступ

Почнемо з того, що важливо вміти розрізняти такі два поняття: аутентифікації та авторизації.Саме за допомогою цих термінів майже всі клієнт-серверні додатки засновують поділ прав доступу у своїх сервісах. Далі нам, як розробникам і як відповідальним людям хочеться переконатися, що цей користувач справді той за кого він себе видає - і тому слід процес аутентифікації, коли користувач підтверджує, що він той %user_name%, наприклад, шляхом введення пароля Здавалося б, все що необхідно виконати для безпеки нашого додатку ми зробили. важливим кроком у будь-якому клієнт-серверному додатку є розмежування прав, дозвіл або заборона тих чи інших дій даного конкретного автентифікованого користувача - процес авторизації. Ще раз коротко закріпимо: спочатку йде ідентифікація та аутентифікація, процеси коли ми визначаємо і засвідчуємося, що за користувач в даний момент використовує наш додаток, а далі йде авторизація - процес прийняття рішення про дозволені даному користувачеві дії.

Ще одне невелике введення

Перш ніж почати говорити про сам токен авторизації слід згадати для яких цілей взагалі його вирішили використовувати.Оскільки ми знаємо, що майже весь інтернет так чи інакше побудований на протоколі HTTP (або його старшому браті HTTPS) і що він не відстежує стан, тобто при кожному запиті HTTP нічого не знає, що відбувалося до цього, він лише передає запити виникає наступна проблема: якщо автентифікація нашого користувача відбувається за допомогою логіну та пароля, то при будь-якому наступному запиті наш додаток не буде знати все той чи ця людина, і тому доведеться щоразу заново логінитися. Вирішенням цієї проблеми є саме наш токен, саме його найпопулярніша реалізація - JSON Web Tokens (JWT). Крім вирішення питань з автентифікацією токен вирішує й іншу не менш важливу проблему авторизації (розмежування дозволених даному користувачеві дій), про те, яким чином ми дізнаємося нижче, коли почнемо розбирати структуру токена.

Формальне визначення

Приступимо нарешті до роботи самого токена. Як я сказав раніше як токени найчастіше розглядають JSON Web Tokens (JWT) і хоча реалізації бувають різні, але токени JWT перетворилися на якийсь стандарт, саме тому розглядатимемо саме на його прикладі.

JSON Web Token (JWT) – це відкритий стандарт (RFC 7519) для створення токенів доступу, що базується на форматі JSON.

Фактично це просто рядок символів (закодований та підписаний певними алгоритмами) з деякою структурою, що містить корисні дані користувача, наприклад ID, ім'я, рівень доступу і так далі. І цей рядок передається клієнтом додатку при кожному запиті, коли є необхідність ідентифікувати та зрозуміти хто надіслав цей запит.

Принцип роботи

Розглянемо принцип роботи клієнт серверних програм, що працюють за допомогою JWT.Насамперед користувач проходить автентифікацію, звичайно ж якщо не робив цього раніше і в цьому є необхідність, а саме, наприклад, вводить свій логін та пароль. Далі додаток видасть йому 2 токена: access token та refresh token (для чого потрібен другий ми обговоримо нижче, зараз йдеться саме про access token). Користувач тим чи іншим способом зберігає його собі, наприклад, у локальному сховищі або сховищі сесій. Потім, коли користувач робить запит до програми API він додає отриманий раніше access token. І нарешті наш додаток, отримавши даний запит з токеном, перевіряє що даний токен дійсний (про цю перевірку, знову ж таки, нижче), вичитує корисні дані, які допоможуть ідентифікувати користувача і перевірити, що він має право на ресурси, що запитуються. У такий спосіб відбувається основна логіка роботи з JSON Web Tokens. https://habr.com/ua/post/336082/

Структура токена

1. Заголовок (header)
2. Корисні дані (playload)
3. Підпис (signature)

Розглянемо кожну частину детальніше.

Заголовок

Це перша частина токена. Вона служить насамперед для зберігання інформації про токене, яка має розповісти про те, як нам прочитати подальші дані, що передаються JWT. Заголовок представлений у вигляді JSON об'єкта, закодованого в Base64-URL Наприклад:

Якщо розкодувати цей рядок отримаємо:

Заголовок містить два головні поля: alg і typ. Поле typ служить для інформації про тип токена, але як я вже згадував раніше, що JWT перетворився на якийсь стандарт, то це поле перестало нести особливий сенс і служить швидше для майбутнього, якщо раптом з'явиться поліпшена версія алгоритму JWT(2.0), яка замінить JWT. Поле alg задає алгоритм шифрування.Обов'язковим для підтримки всіма реалізаціями є алгоритм HMAC з використанням SHA-256, або, як він позначений у заголовку, HS256. До роботи з цим алгоритмом потрібен один секретний ключ, конкретний механізм роботи розглянемо нижче. Для довідки можна також відзначити, що існує і асиметричний алгоритм, який можна використовувати JWT, наприклад, RS256. Для роботи з ним потрібно два ключі – відкритий та закритий. Але у цій статті розглянемо роботу з одним закритим ключем.

Корисні дані

Перейдемо нарешті до корисних даних. Знову ж таки - це JSON об'єкт, який для зручності та безпеки передачі представляється рядком, закодованим у base64. Наочний приклад корисних даних (playload) токена може бути представлений наступним рядком:

Що в JSON форматі є:

Саме тут зберігається вся корисна інформація. Для даної частини немає обов'язкових полів, з найчастіше можна відзначити такі:

iss - використовується для вказівки програми, з якої відправляється токен.

user_id - для ідентифікації користувача в нашій програмі, кому належить токен.

Однією з найважливіших характеристик будь-якого токена є час його життя, яке може бути поставлене полем exp. По ньому відбувається перевірка, чи актуальний токен ще (що відбувається, коли токен перестає бути актуальним можна дізнатися нижче). Як я вже згадував, токен може допомогти з проблемою авторизації, саме в корисних даних ми можемо додати свої поля, які відображатимуть можливості взаємодії користувача з нашим додатком.Наприклад, ми можемо додати поле is_admin або is_preferUser, де можемо вказати, чи має користувач права на ті чи інші дії, і при кожному новому запиті з легкістю перевіряти, чи не суперечать запитувані дії з дозволеними. Ну а що робити, якщо спробувати змінити токен і вказати, наприклад, що ми є адміністраторами, хоча такими ніколи не були. Тут ми плавно можемо перейти до третьої та заключної частини нашого JWT.

Підпис

На даний момент ми зрозуміли, що поки що токен ніяк не захищений і не зашифрований, і будь-хто може змінити його і тим самим порушується взагалі весь зміст аутентифікації. Цю проблему покликана вирішити остання частина токена - саме сигнатура (підпис). Відбувається таке: наш додаток при проходженні користувачем процедури підтвердження, що він той за кого себе видає, генерує цей самий токен, визначає поля, які потрібні, записує туди дані, які характеризують даного користувача, а далі за допомогою заздалегідь вибраного алгоритму (який зазначається у заголовку в полі токена alg), наприклад HMAC-SHA256, і за допомогою свого приватного ключа (або певної секретної фрази, яка знаходиться тільки на серверах додатку) всі дані токена підписуються. І потім сформований підпис додається, також у форматі base64, наприкінці токена. Таким чином наш підсумковий токен є закодованим і підписаним рядком. І далі при кожному новому запиті до API нашої програми сервер за допомогою свого секретного ключа зможе перевірити цей підпис і тим самим переконатися, що токен не був змінений.Ця перевірка є схожою на підпис операцію, а саме, отримавши токен при новому запиті, він виймає заголовок і корисні дані, потім підписує їх своїм секретним ключем, і потім йде просто порівняння двох рядків, що вийшли. У такий нехитрий спосіб, якщо не скомпроментувати секретний ключ, ми завжди можемо знати, що перед нами все ще наш %user_name% з чітко відведеними йому правами.

Час життя токена та Refresh Token

Тепер плавно перейдемо до наступного питання - часу життя токена, і супутньої цієї теми refresh token. Ми пам'ятаємо, що одна з найважливіших властивостей токена – це час його життя. І воно зовсім недовговічне, саме 10-30 хвилин. Може виникнути питання: а навіщо такий короткий час життя, адже тоді доведеться щоразу заново створювати новий токен, а це зайве навантаження на додатки. А відповідь досить очевидна, яка включає в себе і одночасно відповідь на запитання: а що робити, якщо токен був перехоплений. Справді, якщо токен був перехоплений, це велика біда, оскільки зловмисник отримує доступом до додатку від імені нашого %user_name%, але оскільки access token є короткоживущим, це відбувається лише у недовгий період. А далі цей токен вже не валідний. І саме щоб оновити та отримати новий access token потрібен refresh token. Як ми знаємо (або якщо забули можемо знову прочитати на початку) користувач після процесу аутентифікацію отримує обидва ці токені. І тепер після закінчення часу життя access token ми відсилаємо в додаток refresh token і у відповідь отримуємо знову два нових токена, знову ж таки один багаторазовий, але обмежений за часом - токен доступу, а другий одноразовий, але довгоживучий - токен оновлення.Час життя refresh token цілком може вимірюватися місяцями, що достатньо для активного користувача, але якщо і цей токен виявиться не валідним, то користувачеві слід заново пройти ідентифікацію та автентифікацію, і він знову отримає два токена. І весь механізм роботи повториться.

Висновок

У цій статті я постарався докладно розглянути роботу клієнт-серверних додатків із токеном доступу, а саме на прикладі JSON Web Token (JWT). Ще раз хочеться відзначити з якою порівняльною легкістю, але водночас гарною надійністю, токен дозволяє вирішувати проблеми аутентифікації та авторизації, що й зробило його таким популярним. Дякую за час.

Корисні посилання

Токен Авторизації

Крадіжка паролів – це далеко не унікальна подія. Один із перших задокументованих подібних випадків стався ще 1962 року. Людям не просто запам'ятовувати різні комбінації символів, тому вони часто записують усі свої паролі на папері, використовують один і той же варіант у декількох місцях, лише злегка модифікують за допомогою додавання символів або зміною регістру якийсь старий пароль, щоб використовувати його в новому місці. -за що два паролі стають вкрай схожі. Логіни з тієї ж причини часто роблять однакові, ідентичні.

Окрім небезпеки крадіжки даних та складності зі зберіганням інформації, паролі також вимагають перевірки автентичності сервера, що збільшує навантаження на пам'ять. Щоразу, коли користувач входить у систему, комп'ютер створює запис транзакції.

Авторизація токенів - це система, що працює зовсім інакше. За допомогою авторизації токенів вторинна служба перевіряє запит сервера. Після завершення перевірки сервер видає токен і відповідає на запит.Користувач все ще може мати один пароль для запам'ятовування, але токен пропонує іншу форму доступу, яку набагато важче вкрасти або подолати. І запис сеансу не займає місця на сервері. По суті, токен авторизації - це пристрій, призначений для забезпечення інформаційної безпеки користувача, також використовується для ідентифікації його власника. Як правило, це фізичний пристрій, який використовується для спрощення автентифікації.

Типи токенів авторизації

Токени авторизації різняться за типами. Розглянемо їх:

1. Пристрої, які потрібно підключити фізично. Наприклад: ключі, диски тощо. Той, хто будь-коли використовував USB-пристрій або смарт-карту для входу в систему, стикався з підключеним струменом.
2. Пристрої, які знаходяться досить близько до сервера, щоб встановити з'єднання, але воно не підключаються фізично. Прикладом такого типу токенів може бути "magic ring" від компанії Microsoft.
3. пристрої, які можуть взаємодіяти із сервером на великих відстанях.

У всіх трьох випадках користувач повинен щось зробити, щоб запустити процес. Наприклад, ввести пароль або відповісти на запитання. Але навіть коли ці кроки здійснюються без помилок, доступу без токена отримати неможливо.

Процес токен авторизації

Авторизація за допомогою токена відбувається наступним чином. Спочатку людина запитує доступ до сервера чи захищеного ресурсу. Запит зазвичай включає введення логіна і пароля. Потім сервер визначає, чи користувач може отримати доступ. Після цього сервер взаємодіє з пристроєм: ключ, телефон, USB або ще щось. Після перевірки сервер видає токен та відправляє користувачеві. Токен знаходиться у браузері, поки робота продовжується.Якщо користувач спробує відвідати іншу частину сервера, токен знову зв'язується з ним. Доступ надається або навпаки забороняється на основі виданого токена.

Адміністратори встановлюють обмеження на токени. Можна дозволити одноразовий токен, який негайно знищується, коли людина виходить із системи. Іноді встановлюється маркер самознищення в кінці певного періоду часу.

Що таке автентифікація на основі токенів?

Аутентифікація на основі токенів - це один із багатьох методів веб-автентифікації, які використовуються для забезпечення безпеки процесу перевірки. Існує автентифікація за паролем, біометрією. Хоча кожен метод автентифікації є унікальним, всі методи можна розділити на 3 категорії:

1. аутентифікація за паролем (звичайне запам'ятовування комбінації символів)
2. автентифікація з біометрії (відбиток пальця, сканування сітківки ока, FaceID)
3. автентифікація токенів

Аутентифікація токенів вимагає, щоб користувачі отримали згенерований комп'ютером код (або токен), перш ніж їм буде надано доступ до мережі. Аутентифікація токенів зазвичай використовується у поєднанні з аутентифікацією паролів для додаткового рівня безпеки (двофакторна аутентифікація (2FA)). Якщо зловмисник успішно реалізує атаку грубої сили, щоб отримати пароль, йому доведеться обійти рівень аутентифікації токенів. Без доступу до токену отримати доступ до мережі стає важче. Цей додатковий рівень відлякує зловмисників та може врятувати мережі від потенційно катастрофічних порушень.

Як токени працюють?

У багатьох випадках токени створюються за допомогою донглів або брелоків, які генерують новий токен автентифікації кожні 60 секунд відповідно до заданого алгоритму.Через потужність цих апаратних пристроїв користувачі повинні постійно тримати їх у безпеці, щоб вони не потрапили в чужі руки.

Найпоширеніші системи токенів містять заголовок, корисне навантаження і підпис. три елементи працюють разом, щоб створити високоефективну та безпечну систему аутентифікації.

Хоча ці традиційні системи аутентифікації токенів все ще діють сьогодні, збільшення кількості смартфонів зробив аутентифікацію на основі токенів простіше, ніж будь-коли. у будь-який момент часу. У процесі входу в систему користувачі отримують криптографічно безпечний одноразовий код доступу, який обмежений за часом 30 або 60 секундами, в залежності від налаштувань на стороні сервера.

Поява аутентифікації на основі токенів смартфонів означає, що у більшості співробітників вже є обладнання для генерації кодів.

Чи безпечне використання токенів?

У міру зростання кіберзлочинності та ускладнення методів атак мають удосконалюватися методи та політика захисту. Через зростаюче використання атак "грубою силою", перебору за словником і фішингу для захоплення облікових даних користувачів стає цілком очевидно, що автентифікації по паролю вже недостатньо, щоб протистояти зловмисникам.

Аутентифікація на основі токенів, коли вона використовується в тандемі з іншими методами аутентифікації, створює бар'єр 2FA, призначений для того, щоб зупинити навіть найпросунутішого хакера. Оскільки токени можуть бути отримані тільки з пристрою, який їх виробляє - брелок або смартфон, системи авторизації токенів вважаються дуже безпечними і ефективними.

Але, незважаючи на безліч переваг, пов'язаних із платформою токенів, завжди залишається невеликий ризик. Звичайно, токени на базі смартфонів неймовірно зручні у використанні, але смартфони також є потенційними вразливими. Токени, надіслані як текстів, більш ризиковані, оскільки їх можна перехопити під час передачі. Як і у випадку з іншими апаратними пристроями, смартфони також можуть бути втрачені або вкрадені та опинитися в руках зловмисників.

Рекомендації щодо автентифікації на основі токенів

Реалізація надійної стратегії аутентифікації має вирішальне значення, коли йдеться про те, щоб допомогти клієнтам захистити свої мережі від порушення безпеки. Але для того, щоб стратегія справді була ефективною, потрібне виконання кількох важливих основних умов:

1. Правильний веб-токен. Хоча існує низка веб-токенів, жоден з них не може забезпечити ту ж надійність, яку надає веб-токен JSON (JWT).JWT вважається відкритим стандартом (RFC 7519) передачі конфіденційної інформації між кількома сторонами. Обмін інформацією здійснюється цифровим підписом з використанням алгоритму або поєднання відкритого та закритого ключів для забезпечення оптимальної безпеки.
2. Приватність.
3. Використання HTTPS-з'єднань. HTTPS-з'єднання були побудовані за допомогою протоколів безпеки, що включають шифрування та сертифікати безпеки, призначені для захисту конфіденційних даних. Важливо використовувати HTTPS-з'єднання, а не HTTP або будь-який інший протокол з'єднання під час відправлення токенів, оскільки в іншому випадку зростає ризик перехоплення з боку зловмисника.

Що таке JSON веб-токени?

JSON Web Token (JWT) – це відкритий стандарт (RFC 7519), який визначає компактний та автономний спосіб безпечної передачі інформації між сторонами у вигляді об'єкта JSON. Цю інформацію можна підтвердити завдяки цифровому підпису. JWT може бути підписаний секретом (за допомогою алгоритму HMAC) або іншим чином, наприклад, за схемами RSA або ECDSA.

У компактній формі веб-токени JSON складаються з трьох частин, розділених точками: заголовок, корисне навантаження, підпис. Тому JWT виглядає зазвичай так: «xxxx.yyyy.zzzz».

Заголовок складається з двох частин: типу токена, яким є JWT, і алгоритму підпису, такого як HMAC SHA256 або RSA.

Друга частина токена - це корисне навантаження, що містить інформацію про користувача та необхідні додаткові дані. Така інформація буває зареєстрованою, публічною та приватною.

Зареєстрована - це набір ключів, які не є обов'язковими, але рекомендуються для забезпечення покращення безпеки. Наприклад, iss – унікальний ідентифікатор сторони, що генерує токен, exp – час у форматі Unix Time, що визначає момент, коли токен стане не валідним, та інші.

Публічна інформація може бути визначена за бажанням тими, хто використовує JWT. Але вони мають бути визначені в реєстрі веб-токенів IANA JSON або визначені як URI, який містить стійкий до колізій простір імен. Приватна - це інформація користувача, створена для обміну даними між сторонами, які згодні їх використовувати. Отримаємо другу частину за допомогою кодування Base64Url.

Теж не зрозумів, що за прикол там відбувається.

Підпис же використовується для перевірки того, що повідомлення не було змінено шляхом, а у випадку токенів, підписаних закритим ключем, він також може підтвердити, що відправник JWT той, що за себе видає.

Вихідні дані є три рядки Base64-URL, розділені точками, які можуть бути легко передані в середовищах HTML і HTTP, будучи при цьому більш компактними порівняно зі стандартами на основі XML, такими як SAML.

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKb2h uIEdvbGQiLCJhZG1pbiI6dHJ1ZX0K.LIHjWCBORSWMEibq-tnT8ue_deUqZx1K0XxCOXZRrBI

До переваг використання JWT можна віднести розмір - токени в цій мові коду крихітні і можуть бути передані між двома користувачами досить швидко; простоту – токени можуть бути згенеровані практично з будь-якого місця, і їх не потрібно перевіряти на сервері; контроль - можна вказати, до чого користувач може отримати доступ, як довго триватиме ця роздільна здатність і що він може робити під час входу до системи.

До мінусів варто віднести лише один ключ - JWT покладається на один ключ, через що вся система опиниться під загрозою у разі, якщо він буде скомпрометований; складність - JWT токени не так просто зрозуміти, через що розробник, який не володіє глибокими знаннями алгоритмів криптографічного підпису, може ненавмисно поставити систему під загрозу; обмеження - немає можливості надсилати повідомлення всім клієнтам, і неможливо керувати клієнтами з боку сервера.

Чому варто використовувати токени авторизації?

Багато людей вважають, що якщо поточна стратегія працює добре (нехай і з деякими помилками), немає сенсу щось змінювати. Але токени авторизації можуть принести багато вигод.

Вони хороші адміністраторів систем, які часто надають тимчасовий доступ, тобто. база користувачів коливається залежно від дати, часу чи особливої ​​події. Багаторазове надання та скасування доступу створює серйозне навантаження на людей.

Токени авторизації дозволяють забезпечити детальний доступ, тобто. сервер надає доступ на основі певних властивостей документа, а не властивостей користувача. Традиційна система логінів та паролів не допускає такого тонкого налаштування деталей.

Токени авторизації можуть забезпечити підвищену безпеку. Сервер містить конфіденційні документи, які можуть завдати компанії або країні серйозної шкоди під час випуску. Простий пароль не може забезпечити достатній захист.

Є й інші переваги використання цієї технології. Але навіть перерахованих вже достатньо, щоб впровадити її на сервера.