jwt кстати. народ не дочитал не доразобрался, но у меня возникло ошушение на которое проще сейчас спросить об ответе да/нет - jwt сам в себе содержит данные которые в него засовывают так? всмысле эта строка по ключу распаковывается и внутри допустим могут быть некоторые данные?

в условиях микросервисов имеет смысл jwt использовать как сесия токен. тогда не надо обращатся к базе токенов (сессий) для идентификации источника запроса и его уровня прав...

в условиях микросервисов имеет смысл jwt использовать как сесия токен. тогда не надо обращатся к базе токенов (сессий) для идентификации источника запроса и его уровня прав...

в условиях микросервисов имеет смысл jwt использовать как сесия токен. тогда не надо обращатся к базе токенов (сессий) для идентификации источника запроса и его уровня прав...

придется проверять заблочен или нет и всё равно получать данные о правах пользователя и т.д.

Можно забить на заблоченные.

профита от jwt меньше нуля. ибо идет нагрузка на валидацию подписи

Использовать отдельный сервер для сессий?

Использовать отдельный сервер для сессий?

и получить дырку

Ну точнее есть схема с двумя токенами, когда один короткий, типо 5 минут, и длинный. Длинный 2 недели или бесконечный. Длинный имеет чёрный лист и вот это вот всё, раз в 5 минут получаем короткий по длинному, авторизацию проводим коротким. В итоге быстро и безопасно

и длинный надо сходу менять после получения короткого

и длинный надо сходу менять после получения короткого

И заносить старый в чёрный список

зачем. Удалять просто из базы

зачем. Удалять просто из базы

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

Client -> Auth Service -> Sessions Service > Auth Service -> Client

есть в базе — валиден

Client -> Auth Service -> Sessions Service > Auth Service -> Client

Так фишка jwt в том что в базе он не лежит

не совсем понимаю назначение каждого сервиса и почему двойной проход через auth

Клиент шлёт Auth Service username:password для авторизации, он чекает в своей бд валидность. Есть успешно - шлёт Sessions Service запрос с нужными данными, для создания сессии. Если сессия не существует, создаётся. Шлётся клиенту сообщение об успешной авторизации.

Хорошо, как клиент узнаёт что он авторизован? С тем же JWT, токен хранился в localStorage и я чекал по нему

Причём Httponly

@dskrylnikov только куки советуешь из-за того что токен утечь может?

Хорошо, как клиент узнаёт что он авторизован? С тем же JWT, токен хранился в localStorage и я чекал по нему

обычный токен у себя держит. лучше в httponly куке

то есть, Auth Service при создании сессии, отправляет её клиенту, тот пишет её в httponly cookie?

JWT или сессии?

@dskrylnikov только куки советуешь из-за того что токен утечь может?

http only может записать только сервер

У меня SSR, сложновато будет немного

как быть с разными доменами? )

если есть под рукой ссылочка на простоту уведения токена из localStorage буду рад.

не будет

{2,13}

пасиба!

Любое расширение в браузере имеет к нему доступ

На сервере SSR принимать запрос?

Кстати, как насчёт passportjs?

t.me/why_jwt_is_bad в самом начале картинка

Чувак (оффтоп) зачем ты колекционируешь плохие стороны всего?

Чувак (оффтоп) зачем ты колекционируешь плохие стороны всего?

На счет jwt в целом, есть видео , https://youtu.be/vQldMjSJ6-w где тема разжовывается подробно в 4 кажется роликах.

В продакшне можно использовать, но многих напрягает то, что он на коллбеках построен

Есть аналоги достойные?

Ну кому заходит кому нет ) мне ок)

JWT?