Какво е JWT? Разбиране на JSON уеб токени и удостоверяване без състояние

Когато влезете в модерно приложение за една страница (като React или Vue) или мобилно приложение, сървърът се нуждае от начин да запомни кой сте. Традиционно той правеше това чрез съхраняване на „ID на сесия“ в масивна база данни на сървъра и пускане на бисквитка в браузъра ви. Всеки път, когато щракнете върху бутон, сървърът трябваше да търси този идентификатор в своята база данни. Това се нарича удостоверяване с пълно състояние.

Въпреки това, в ерата на микроуслугите и облачното мащабиране, базите данни се превърнаха в тясно място. За да решат това, разработчиците приеха Удостоверяване без състояние чрез JSON уеб токени (JWT). С JWT не е необходимо сървърът да помни кой сте - вашият браузър казва на сървъра точно кой сте и използва криптография, за да го докаже.

Анатомията на JWT

Ако проверите мрежовия трафик, след като влезете в модерно приложение, вероятно ще видите заглавка „Упълномощаване: Носител“, последвана от дълъг, произволно изглеждащ низ от знаци, разделени с две точки. Това е JWT.

JWT се състои точно от три части: Header.Payload.Signature.

1. Заглавката

Първата част е JSON обект, кодиран с Base64URL, който просто описва токена. Обикновено съдържа две свойства: типа на токена (JWT) и използвания алгоритъм за подписване (като HMAC SHA256 или RSA).

2. Полезният товар (искове)

Средната част също е JSON обект, кодиран с Base64URL. Това е мястото, където живеят действителните данни. Тези части от данни се наричат ​​„претенции“. Например може да съдържа вашето потребителско име, вашата роля (напр. „Администратор“) и клеймо за дата на изтичане. Тъй като този полезен товар е прикачен към всяка заявка, сървърът незабавно знае кой сте, без да прави заявки към база данни.

КРИТИЧНО ПРЕДУПРЕЖДЕНИЕ: Полезният товар е само кодиран, не криптиран. Всеки, който прихване JWT, може лесно да го декодира и да прочете полезния товар. Никога не съхранявайте пароли, социалноосигурителни номера или чувствителни данни в JWT полезен товар.

3. Подписът

Ако някой може да чете и редактира полезния товар, какво спира злонамерен потребител да промени ролята си от „Потребител“ на „Администратор“? Отговорът е Подписът.

За да създаде подписа, сървърът взема заглавката, полезния товар и високо защитен Таен ключ (известен само на сървъра) и ги пуска през криптографски алгоритъм (като SHA256). Полученият хеш става подпис.

Когато сървърът получи токен обратно от клиента, той преизчислява подписа, използвайки своя таен ключ. Ако потребителят се подмени с полезния товар (дори промени една буква), преизчисленият подпис няма да съответства на подписа върху токена и сървърът незабавно ще отхвърли заявката като измамна.

Защо микроуслугите обичат JWT

Представете си компания като Netflix. Те имат сървър за удостоверяване, сървър за видео стрийминг и сървър за таксуване. Ако използваха традиционни сесии, всеки отделен сървър ще трябва постоянно да комуникира с централна база данни, за да провери дали даден потребител е влязъл.

С JWT сървърът за удостоверяване подписва токена с помощта на частен ключ. След това потребителят предава този токен директно на видео сървъра. Тъй като видеосървърът има публичен ключ, той може независимо да провери подписа. Видео сървърът знае точно кой е потребителят, без изобщо да говори със сървъра за удостоверяване или база данни. Това позволява на инфраструктурата да се мащабира безкрайно без затруднения.

Тъмната страна: Обезсилване на токена

JWT не са перфектни. Най-голямата им сила (апатридите) е и най-голямата им слабост. Тъй като сървърът не поддържа запис на активните токени, не можете лесно да излезете от потребител или да направите невалиден конкретен токен, преди да изтече.

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

• Означения за достъп: Краткотрайни JWT (напр. 15 минути), използвани за API заявки.
• Ознаки за опресняване: Дълготрайни токени за състояние, съхранявани сигурно, използвани стриктно за заявяване на нови токени за достъп. Ако даден акаунт е компрометиран, сървърът отменя Refresh Token и Access Token на хакера естествено ще умре след 15 минути.

Често задавани въпроси (FAQ)