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.