JSON Web Token

JSON Web Token (JWT, МФА: [dʒɒt], вимовляється "джот"^[1]) це стандарт токена доступу на основі JSON, стандартизованого в RFC 7519. Використовується для верифікації тверджень.

Структура

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

Заголовок

Заголовок (Header) це JSON елемент, який описує до якого типу токену належить даний і які методи шифрування використовувались.

Поле	Назва	Значення
typ	Type	Описує медіатип IANA Medientyp токену. В даному випадку `JWT` завжди мають медіатип`application/jwt`.
cty	Content Type	Це поле потрібне, коли JWT вміщає в себе інший JWT. Тоді воно встановлюється в JWT. В інших випадках це поле пропускається.
alg	Algorithm	Описує використаний алгоритм шифрування. Зазвичай використовують HMAC з SHA-256 (`HS256`) або RSA з SHA-256 (`RS256`). Можна також не використовувати жодного шифрування, вказавши `none`, але це не рекомендується. Можливі значення вказуються в стандарті JSON Web Encryption (JWE) RFC 7516.

Заголовок може наприклад виглядати так:

{
  "alg": "HS256",
  "typ": "JWT"
}

Вміст

Вміст (англ. Payload) складається з елемента JSON який описує твердження.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Деякі твердження зарезервовані:

Поле	Назва	Значення
iss	Issuer	Той хто видав токен
sub	Subject	Визначає якого суб'єкта стосуються твердження, тобто щодо кого або чого робляться твердження.
aud	Audience	Цільова аудиторія токена.
exp	Expiration Time	Час закінчення терміну дії токена в форматі Unix (кількість секунд що пройшли від `1970-01-01T00:00:00Z`).
nbf	Not Before	Час в форматі Unix до настання якого токен не дійсний.
iat	Issued At	Коли токен був виданий (в форматі Unix)
jti	JWT ID	Унікальна, чутлива до регістру послідовність символів, яка однозначно ідентифікує токен. Може застосовуватись для запобігання повторному використанню токена. Це можуть бути порядкові числа, GUID або Хеш.

Решта - це Public Claims які визначаються IANA.^[2] Крім того, той хто видає JWT може також додати Private Claim використавши URI, що, щоправда не є стандартизованим. Наприклад, тут може бути використана якась онтологія, на зразок Дублінського ядра або FOAF.

Підпис

Структура підпису визначається стандартом JSON Web Signature (JWS, RFC 7515).

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

var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
var hash = HMACSHA256(encodedString, secret);

Кодування

Заголовок, вміст і підпис кожен кодуються в Base64 і розділяються в токені крапкою. JWT Token може виглядати так:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzY290Y2guaW8iLCJleHAiOjEzMDA4MTkzdHJ1ZX0.03f329983b86f7d9a9f5fef85305880101d5e302afafa20154d094b229f75773

Передача за допомогою HTTP

JWT передається в заголовках HTTP, зазвичай двома способами:

в полі Authorization як Bearer-Token: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
в полі Cookie: Cookie: token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Обидва методи мають різні переваги і недоліки:

	Bearer-Token	Cookie
Заголовок	`Authorization: Bearer <JWT>`	`Cookie: token=<JWT>`
CORS	Працює з CORS, проте необхідна реалізація на JavaScript.	Кукі зберігаються в браузері лише для конкретного домену, CORS неможливий.
Зберігання	Можливі всі способи зберігання доступні для JavaScript, як наприклад WebStorage чи Cookie-Store.	Cookie розміщуються в Cookie-Store.
Захист від MITM	Наявність TLS повинна перевірятись в JavaScript.	Коли на кукі встановлюється прапорець `secure`, тоді примусово застосовується TLS.
Захист від XSS	Повинен реалізовуватись в JavaScript.	Неявний, якщо для кукі встановлено прапорець `HttpOnly`, для запобігання доступу через JavaScript.
Захист від CSRF	Неможливий. Необхідні інші заходи.	Повинен реалізовуватись в JavaScript

Реалізації

Реалізації JWT доступні на безлічі платформ. Акуальний список можна знайти на сайті JWT.io^[3]

Security Event Token

Security Event Token (SET) розширює стандарт JWT твердженням events, яке містить список подій що стосуються безпеки.^[4] Ці токени містять відмітку часу і дійсні необмежений час. Вміст SET-токена може виглядати наступним чином:

{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  }
}

SET можуть використовуватись для аудиту^[de]. На даний час (травень 2018) IETF поки що не створило для SET офіційного RFC.

Див. також

Security Assertion Markup Language (SAML)
Simple Web Token (SWT)
OAuth та OpenID

Джерела

↑ Scalable Microservices with Kubernetes - Udacity
↑ JSON Web Token Claims. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)
↑ JWT. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)
↑ Security Event Token (SET) Specification and IETF Security Events Working Group. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)

[1] Scalable Microservices with Kubernetes - Udacity

[public-2] JSON Web Token Claims. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)

[implementations-3] JWT. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)

[selfissued-4] Security Event Token (SET) Specification and IETF Security Events Working Group. {{cite web}}: Cite має пустий невідомий параметр: |1= (довідка)

[1]

[2]

[3]

[4]