Надеюсь что разработчики софта в банках, не ходят советоваться как делать jwt в чатики телеграма

Банковские это можно понять, но там это по сути даже не связано с использование jwt

Я тоже что у них есть свое решение хотя скорей всего они все юзают crypto. Потому что чтоб реализовать подобное нужно быть чертовски гениальным чуваком или чуваками ))

я понимаю что бесит. Вопрос насколько решение адекватное. Нужно продлевать сессию только когда юзер пользуется

Посмотри похожие проекты на твой, у кого нибудь действительно есть короткоживущие сессии ?

Ребят, до этого все время использовал https (модуль), сейчас хочу попробовать http2. В чем будет принципиальная разница вообще?

Лекцию бы конечно по https и http2... 🙏🏻 И не в том смысле, только как юзать API и exampl'ы. А услышать всякие полезные вещи о работе с этими протоколами,  аля подводные камни и актуальные/не актуальные места и способы применения, как это Тимур обычно рассказывает.

А чем документация и статьи не подходят?
Пока ждать лекцию можно (и нужно) самому разобраться.

Вообщем-то я это и делаю, но такой тезис тогда можно применить и ко всем лекциям которые Тимур уже сделал по Ноде. Многие нюансы ты из доки не узнаешь, о чем я и написал выше, что Тимур часто не просто разжевывает API, а еще дает полезную информацию.

А сессия тоже нигде не хранится?

Это jwt, нет сессии

https://auth.nuxtjs.org/ я вот такое юзаю

Ну как это нет?
Пользователь залогинился и имеет доступ к ресурсу на протяжении фиксированного времени. Это называется пользовательская сессия. Какая разница что там под капотом, JWT или session cookie?

То, что JWT не предназначен для сессий, это отдельный вопрос.

Я как-то написал свою реализацию аутентификации:
При старте новой сессии генерируется sessionId (uuid) и synctoken (uuid) и session token который содержит в себе: payload:{sessionid, ... }, synctoken, sessionTokenCreationTime, sessionTokenExpTime, sessiontokenSign основанный на предыдущей части.
Клиенту отдается sessiontoken в куках и synctoken в headers. Sessiontoken обновляется в течение заданной на сервере константы, допустим 15 минут, и вместе с ним выпускается новый synctoken. SessionId при этом не обновляется. SessionTokenExp это по сути время через которое sessiontoken уже не сможет обновляться и придется перелогинится. Обычно это время большое, хоть полгода, но ты можешь сделать и 20 минут.
Может тебе подходит это решение. SessionId по сути можно и не хранить. Но я тогда не знаю как ограничивать кол-во сессий на аккаунте.

Забавно. Не хочу показаться грубым, но я просил поругать/обсудить мое решение. В итоге получил стандартный философский вопрос 'а нужны ли вам jwt вообще' от гуру. Совет посмотреть похожие решения (ведь я наверное не смотрел). Ссылку на либу с комментарием 'у меня так' из совсем других фреймворков которое непонятно как работает и потянет кучу времени чтобы разбираться что же там под капотом и то ли это вообще что мне нужно. И какое-то третье решение которое не очень ясно и в котором разбираться не очень хочется из-за его неясности т.к.это очень растянет переписку. Но никто ничего не сказал о моем решении. И вроде бы отметились...Программисты тоже люди....

Так то что ты написал, больше имеет отношение к фронтенд-реализации. Можешь сделать как ты написал.

иронично что вы в своем перечислении к примеру упустили мой комментарий про то, что одноразовость рефреша - важная деталь беопасности (который был ПЕРВЕЕ вопроса "а вам точно надо именно jwt?")

Программисты тоже люди :)

Если честно я вообще не очень понял его вопрос. Выглядит так будто, "как давать доступ к ограниченным ресурсам без токенов".

не

речь шла о том, что выкинуть рефреш токен и использовать вместо него аксес