Novikov on Soapbox

В чём крутость JWT

Представьте что у вас есть кафе, банк, whatever сервисное. Вы живёте в футуристической антиутопии, где все двери у вас открываются только по распознаванию лица. То есть вообще все. То есть даже входная дверь в магазин. И вот в один прекрасный день микросервис для управления дверями приглючивает, он падает и при определённых условиях запирает все двери.

Это же кошмар! Сотрудники оказываются заперты в своих кабинетах. Клиенты не могут войти, а те кто вошёл не могут выйти! И стоят бедненькие за окном, облизываются. Ну вот как у меня с Яндекс.Паспортом было.

Что же предлагает JWT? А JWT в этой ситуации предлагает отличное решение: а давайте мы, мол, вместо центрального микросервиса управления дверями тупо сделаем блин в них замки. А ключи вахтёр выдавать будет. Скажем, на час работы. Заходишь, берёшь связку ключей которая тебя уготована админами — и вперёд. Пользоваться сервисами. Если вахтёр отойдёт попить чайку, скажем, то ничего страшного не произойдёт.

Тут не без минусов, конечно. Например, вахтёр не может добежать до пользователя и отобрать у него ключ в случае если тот начал творить неладное. Но может, например, крикнуть всем дверям заклинание, которое прикажет такой-то ключик не пущать ещё час. Есть, словом, варианты.

Технически это выражается так: при логине, логин-микросервис передаёт клиенту некий JSON, ужатый в base64 для надёжности и подписанный приватным ключом системы. Пользователь его бережёт как зеницу ока и в каждом запросе добавляет, скажем, в заголовок Authentication.

В JSON-е том можно хранить любые данные пользователя. Ну как любые... пароль туда всё же лучше не пихать. А вот информацию, которую вы от пользователя и не скрываете — пожалуйста. Client Id, User Name, Last Login Time, Last Activity Time — вполне. Главное что изменить эту информацию клиентская сторона не может (бо как тогда цифровая подпись не сойдётся).

Ну и собсно в каждом запросе каждый микросервис парсит этот заголовок, расшифровывает JSON, проверяет подпись и если всё ок — процессит запрос. Как видим, никакого централизованного сервиса для этого не надо. А значит что? А это значит что у нас исчезает огромная точка потенциального отказа системы, что повышает её стабильность.

Элегантно. Люблю такие штуки.

Такие дела

www.tgoop.com/reinforced_sc/94

2.3K viewsDec 20, 2021 at 16:00

В чём крутость JWT

Представьте что у вас есть кафе, банк, whatever сервисное. Вы живёте в футуристической антиутопии, где все двери у вас открываются только по распознаванию лица. То есть вообще все. То есть даже входная дверь в магазин. И вот в один прекрасный день микросервис для управления дверями приглючивает, он падает и при определённых условиях запирает все двери.

Это же кошмар! Сотрудники оказываются заперты в своих кабинетах. Клиенты не могут войти, а те кто вошёл не могут выйти! И стоят бедненькие за окном, облизываются. Ну вот как у меня с Яндекс.Паспортом было.

Что же предлагает JWT? А JWT в этой ситуации предлагает отличное решение: а давайте мы, мол, вместо центрального микросервиса управления дверями тупо сделаем блин в них замки. А ключи вахтёр выдавать будет. Скажем, на час работы. Заходишь, берёшь связку ключей которая тебя уготована админами — и вперёд. Пользоваться сервисами. Если вахтёр отойдёт попить чайку, скажем, то ничего страшного не произойдёт.

Тут не без минусов, конечно. Например, вахтёр не может добежать до пользователя и отобрать у него ключ в случае если тот начал творить неладное. Но может, например, крикнуть всем дверям заклинание, которое прикажет такой-то ключик не пущать ещё час. Есть, словом, варианты.

Технически это выражается так: при логине, логин-микросервис передаёт клиенту некий JSON, ужатый в base64 для надёжности и подписанный приватным ключом системы. Пользователь его бережёт как зеницу ока и в каждом запросе добавляет, скажем, в заголовок Authentication.

В JSON-е том можно хранить любые данные пользователя. Ну как любые... пароль туда всё же лучше не пихать. А вот информацию, которую вы от пользователя и не скрываете — пожалуйста. Client Id, User Name, Last Login Time, Last Activity Time — вполне. Главное что изменить эту информацию клиентская сторона не может (бо как тогда цифровая подпись не сойдётся).

Ну и собсно в каждом запросе каждый микросервис парсит этот заголовок, расшифровывает JSON, проверяет подпись и если всё ок — процессит запрос. Как видим, никакого централизованного сервиса для этого не надо. А значит что? А это значит что у нас исчезает огромная точка потенциального отказа системы, что повышает её стабильность.

Элегантно. Люблю такие штуки.

Такие дела

BY Novikov on Soapbox