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 обикновено имат три части: заглавие, полезен товар и подпис. Заглавието идентифицира кой алгоритъм се използва за генериране на подписа, и изглежда по следния начин:

header = '{"alg":"HS256","typ":"JWT"}'

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

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

payload = '{"loggedInAs":"admin","iat":1422779638}'

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

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

key = 'secretkey'

unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)

signature = HMAC-SHA256(key, unsignedToken)

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

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

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

Как работи редактиране

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

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

Authorization: Bearer <token>

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

Вижте повече подробности и онлайн инструменти в 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.

Източници редактиране

Тази страница частично или изцяло представлява превод на страницата JSON Web Token в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите.

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.