Если речь о JWT, то кратко так. При первом login создается 2 токена: access + refresh. У refresh expiration чуть больше. Когда access JWT протухает, это можно проверить даже на front-end стороне с помощью JWT.decode, тогда ты шлешь на сервер авторизации refresh token. И там создаешь и отправляешь 2 новых JWT, access + refresh. Подробнее можно погуглить, на Хабре например.

Дякую, доповнило картину в голові
А саме яким чином перевіряти на фронті ? Читав, що можна запускати таймер на число близьке до того як токен буде експайр та робити запит фоном

То есть access для запросов данных, а refresh только для генерации новых access+refresh. Декорировать его можно один раз при получении и запомнить expiration в стейте.
https://github.com/auth0/jwt-decode

Тут норм розжовано
https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc

Дякую 🦾

@ilyahuman Alexander @K_D_I
Почитайте тут почему jwt это антипаттерн безопасности и масштабирования @why_jwt_is_bad

👍 JWT не використовую. Мій вибір  httponly+samesite+secure cookie.  В посиланні процедура рефреша токенів описана,  її  аналогічно для кук можна використовувати.

Критикуя предлагай, иначе это плохой тон. Так что предложи свой вариант распределенной аутентификации помимо JWT и SSO.

У меня же есть все это в примерах и видео.
1. распределенная аутентификация не нужна, если у вас не миллионы людей одновременно в онлайне. Делать тут распределенность - это грех преждевременной оптимизации.
2. Есле все же нужно будет потом масштабироваться, то можно локальные сессии хранить на каждом сервере и приклеивать пользователей к серверу.
3. Или можно вынести аутентификацию в отдельный сервис, который имеет одну базу и много инстансов. И он вполне выдержит аутентификацию нескольких сотен тысяч в секунду. А это норм для систем с миллиардами пользователей.

Ага, по п.3, вот единый auth service для логина, а как в других микросервисах аутентифицировать? По сути это и есть свое JWT или SSO 😀 И вот еще один момент, сейчас пишут API для web + mobile, это уже стандарт. Есть даже куча проектов, где веба нет, только мобилки. Потому web cookie sessions вообще не вариант.

Я ничего не говорил про куки, можно генерить большие токены рандомные и потом из хоть в куки, хоть хранить локально и предъявлять по rpc через websocket с браузера или по tcp с мобильного. Ни каких проблем. А микросервисы не должны все торчать во внешний мир, а даже если и тгрчат, то они могут проверять токены в специальном auth сервисе.

Так и чем это отличается от JWT? Генерировать подписанные токены с expiration, опционально с возможностью рефрешить, хранить их где-угодно (лучше где секьюрно) и передавать любым удобным способом (лучше шифровать траффик) 😀

В любом случае придется решать задачи: где и как хранить, как экспайрить и разлогинивать, как передавать, как их верифицировать, как бороться с украденными токенами и т.д. Эти задачи надо решать в любом случае, что с кастомными токенами, что с JWT. Я не вижу вообще никаких отличий, очередной велосипед.

одно из основных приемуществ использования jwt в качестве источника авторизации клиента - возможность в пейлоаде передать необходимую для этого информацию и без обращения к какому-то централизованному месту
но когда авторизация при каждом запросе идет с помощю jwt а потом дополнительно все равно идет запрос к какому-то источнику (сервис, база) - тогда действительно главная суть использования jwt теряется
вчера человек задал вопрос относительно реализации silent refresh - я так понимаю в контексте стандартного веб-апликейшина  
в таком случае действительно использование cookies + http only позволяет вообще не парится относительно вот таких вопросов

но если мы говорим не про веб (мобайл или  коммуникация между сервисами) - то это впринице уже стандартная задача которая давно реализованна

Согласен, я не являюсь каким-то JWT evangelist 😀 И если после разговора с бизнесом выяснилось, что будет только веб, то самое лучшее решение это HTTP only cookie sessions + шареное хранилище сессий в том же Redis

Саме через необхідність перевірки white/blacklist не використовую )

Народ, кто юзает JWT — вы вообще в курсе, что он по спеке при проверке токена (то есть до подверждения его валидности) ходит по урлам, указанным в этом токене?

От этого пока всё вокруг не сгорело скорее всего потому, что в либах JWТ эту часть пока не реализовали (JWT ­— заоверенжинерен, с реализациями плохо всё).