JSON Web Token часто називають токеном авторизації, але це пояснення пропускає головну ідею. JWT є компактним контейнером для claims — тверджень про користувача, issuer, audience, строк дії та інші властивості. Будь-хто, хто має токен, може прочитати більшість цих даних. Криптографічний підпис дозволяє отримувачу перевірити, що повідомлення створив довірений issuer і після підписання його не змінили.

Три сегменти виконують різні ролі

Типовий підписаний JWT складається з трьох частин, розділених крапками. Header вказує тип токена й алгоритм. Payload містить claims у JSON. Signature захищає закодовані header і payload. Сегменти використовують Base64URL, щоб без проблем передаватися в HTTP-заголовках, cookie та посиланнях.

Base64URL є кодуванням, а не шифруванням. Для декодування перших двох сегментів секрет не потрібен. Це навмисна властивість: сервіси можуть читати claims, покладаючись на підпис для довіри. Паролі, приватні ключі й конфіденційні дані не повинні потрапляти у звичайний signed JWT.

Що саме доводить підпис

Issuer підписує точне текстове представлення header і payload. Для symmetric algorithm перевіряльник використовує той самий secret. Для asymmetric algorithm issuer підписує private key, а сервіси перевіряють відповідним public key. Будь-яка зміна захищених байтів робить підпис неправильним.

Правильний підпис доводить лише відповідність певному ключу. Сервіс усе одно має визначити, чи належить ключ довіреному issuer, чи дозволений алгоритм і чи claims підходять для поточного запиту. Криптографія підтримує рішення про довіру, але не замінює політику.

Стандартні claims створюють спільну мову

JWT визначає відомі назви: iss для issuer, sub для subject, aud для audience, exp для expiration і nbf для not-before. На рівні формату вони необов’язкові, але безпечний застосунок зазвичай вимагає кілька з них.

Audience не дозволяє використати токен одного сервісу в іншому. Issuer validation відсікає правильно підписані токени від недовіреного джерела. Time claims обмежують період, протягом якого вкрадений або застарілий токен залишається корисним.

Чому JWT зручний у розподілених системах

Сервіс може локально перевірити токен без звернення до спільного session store на кожен запит. Public-key підпис дозволяє багатьом сервісам перевіряти claims, не надаючи їм можливості створювати нові токени. Це зручно для API, кількох backend і делегованого доступу.

Плата за автономність — складніше відкликання. Самодостатній токен може залишатися валідним до exp навіть після зміни ролі або блокування облікового запису. Короткі строки, refresh flow, rotation і цільові revocation механізми зменшують ризик, але не усувають керування життєвим циклом.

Підпис і шифрування вирішують різні задачі

Більшість JWT в API є signed token: вміст видно, а підпис захищає цілісність і походження. JSON Web Encryption дозволяє приховати claims, але додає рішення щодо ключів, алгоритмів і сумісності. Шифрування потрібне лише за чіткої вимоги конфіденційності.

Навіть encrypted bearer token потрібно захищати від викрадення. Отримувач може прийняти його на основі володіння, не знаючи, хто саме подав токен.

JWT не завжди є найкращою сесією

Opaque session identifier простіше відкликати, він не розносить дані користувача й добре підходить звичайному вебзастосунку. JWT стає корисним, коли claims мають перейти між незалежними сервісами або бути перевіреними без центрального lookup. Використання токена без такої потреби може лише додати складність.

Великий payload передається з кожним запитом, збільшує заголовки й заохочує поміщати в токен надто багато authorization state. Claims стають застарілими одразу після зміни ролей. У токені варто залишати лише стабільну й потрібну інформацію.

Перевірка повинна бути строгою

Verifier має отримувати allowed algorithms із конфігурації, а не сліпо довіряти header. Він перевіряє issuer, audience, expiration, not-before та application-specific claims. Вибір ключа повинен залишатися в контрольованому наборі, щоб вхідний token не міг указати довільне джерело ключа.

Логи не повинні зберігати повні bearer tokens. Для діагностики достатньо безпечного token ID, issuer, причини відмови й request ID. Той, хто отримав валідний bearer token, часто може використати його як credential.

Транспорт токена є частиною дизайну

JWT часто передають через Authorization: Bearer, але це не єдина можливість. Cookie, message queue та service-to-service metadata мають різні ризики й обмеження. Token у URL майже завжди погана ідея, бо адреса потрапляє в історію, логи та referrer.

Застосунок має визначити максимальний розмір token і врахувати ліміти proxy та gateway. Надмірно великий payload може спричинити 431 або інші помилки ще до того, як запит дійде до authentication middleware.

Clock skew потребує обмеженої політики

Сервіси можуть мати невелику різницю часу, тому verifier часто дозволяє кілька секунд tolerance для exp і nbf. Безмежна поблажливість фактично подовжує строк дії token і робить time claims марними.

Усі машини повинні синхронізувати час, а допустимий skew — бути однаковим і задокументованим. Незвичайна кількість time validation failures може вказувати на проблему інфраструктури або клієнта.

Чіткі часові правила також спрощують тестування граничних моментів.

Це зменшує випадкові відмови.

Політика часу має бути єдиною.

Її треба тестувати.

JWT — це підписане повідомлення, а не магічна ідентичність

JWT добре працює, коли системі потрібен переносний набір claims, який можна незалежно перевірити. Безпека виникає з правильного алгоритму, довірених ключів, strict claim validation і розумних строків дії.

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