Преглед на кода на JSON Web Token

'''JSON Web Token''' (JWT) е JSON-базиран отворен стандарт (RFC 7519) за създаване на „жетони“, които съдържат определен брой твърдения. Например, един сървър може да генерира жетон, който съдържа твърдението „влязъл като администратор“ и достави тази информация до клиент. Клиентът тогава може да използва това означение да докаже, че е влязъл като администратор. Жетоните са подписани от ключа на сървъра, така че сървърът да е в състояние да удостовери, че подписът е законен. Жетоните са проектирани да бъдат компактни, URL-безопасни и използваеми най-вече в уеб браузър единично влизане (SSO) контекст. Твърденията JWT обикновено се използват, за да се предаде самоличността на регистрирани потребители между доставчик на идентичност и доставчик на услуга, или всякакъв друг вид твърдения, както се изисква от бизнес процесите. Жетоните могат да бъдат потвърдени и криптирани.

JWT разчита на други JSON-базирани стандарти: (JSON Web Signature) RFC 7515 и JWE (JSON Web Encryption) RFC 7516.

== Структура ==
JWTs обикновено имат три части: заглавие, полезен товар и подпис. Заглавието идентифицира кой алгоритъм се използва за генериране на подписа, и изглежда по следния начин:

<code>header = '{"alg":"HS256","typ":"JWT"}'</code>

HS256 показва, че този жетон е подписан с помощта HMAC-SHA256.

Полезният товар съдържа твърденията, които искаме да добавим:

<code>payload = '{"loggedInAs":"admin","iat":1422779638}'</code>

Както се предлага в спец JWT, включваме дата и час, наречени IAT, съкратено от „издаден в“.

Подписът се изчислява чрез base64url кодиращи заглавието и полезния товар и ги слепва с точка за разделител:

<code>key = 'secretkey'</code>

<code>unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)</code>

<code>signature   = HMAC-SHA256(key, unsignedToken)</code>

Вземайки всичко заедно, ние кодираме подписа с base64url, и присъединяваме трите части, използвайки точки:

<code>token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) # token is now: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CspyHI</code>

Изходът е три Base64 низа, разделени с точки, които могат лесно да бъдат прехвърлени в HTML и HTTP среди, като същевременно е по-компактен в сравнение с XML-базирани стандарти като SAML. Типични криптографски алгоритми, които са използвани, са HMAC с SHA-256 (HS256) и RSA подпис с SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 въвежда много повече за удостоверяване както и криптиране.

== Как работи ==
В удостоверяване, когато потребителят успешно се регистрира, използвайки своите данни, JSON Web Token ще бъдат върнат и трябва да бъде запазен локално (обикновено в локално пространство, но също така могат да се използват и бисквитки), вместо традиционния подход за създаване на сесия в сървър и връщане на бисквитка.

Всеки път, когато потребителят поиска да получи достъп до защитен път или ресурс, потребителската програма трябва да изпрати JWT, обикновено в Авторизационната заглавна част, използвайки схемата Носител. Съдържанието на заглавието трябва да изглежда по следния начин:

<code>Authorization: Bearer <token></code>

Това е нестатичен механизъм за удостоверяване като състоянието на потребителя никога не е записано в паметта на сървъра. Защитените пътища на сървъра ще проверяват за валиден JWT в заглавната част на Авторизиращата заглавна част, и ако той е налице, на потребителят ще бъде позволено да получи достъп до защитените ресурси. Както JWTs са самостоятелни, цялата необходима информация е налице, намалявайки необходимостта да запита базата от данни на няколко пъти.

[https://jwt.io/ Вижте повече подробности и онлайн инструменти в JWT.io]

== Стандартни полета ==
Интернет заявките дефинират следните стандартни полета („твърдения“), които могат да бъдат използвани в JWT набор от твърдения:
* Issuer(iss) – идентифицира емитента, който е издал JWT;
* Subject(sub) – идентифицира предмета на JWT;
* Audience (aud) – „aud“ (публика) твърдението идентифицира получателите, че JWT е предназначен за тях. Всеки, предназначен да обработи JWT ТРЯБВА да се идентифицира със стойност в публичното твърдение. Ако този, който обработва твърдението не се идентифицира със стойност в „aud“ твърдението, когато е налице, тогава JWT трябва да бъде отхвърлен.
* Expiration time (exp) – „exp“ (време на изтичане) твърдението идентифицира времето на изтичане, след което JWT не трябва да се приема или обработва.
* Not before (nbf) – подобно, „не след“ твърдението идентифицира момента, в който JWT ще започне да е годен за обработване.
* Issued at (iat) – „iat“ (повдигнато в) твърдението идентифицира времето, в което е бил издаден JWT.
* JWT ID (jti) – чувствителен към големината на шрифта идентификатор на жетона дори и сред различни емитенти.

Следните полета могат да се използват за удостоверяване заглавията:
* Token type (typ) – тип на жетона
* Content type (cty) – това твърдение винаги трябва да е JWT
* Message authentication code algorithm (alg) – Емитентът може свободно да определя алгоритъм за проверка на подписа върху жетона. Въпреки това, някои от поддържаните алгоритми са несигурни.
* Всички други заглавия, въведени от JWS и JWE.

== Приложения ==
JWT приложения съществуват за Clojure, .NET (Public domain software), Go, Haskell, Python, Node.js, Java, JavaScript, Lua, Perl, PHP, Ruby, Rust, Scala, and Elixir.

== Източници ==
<references />
{{Превод от|en|JSON Web Token|749475655}}

[[Категория:Системно администриране]]
[[Категория:Компютърна сигурност]]