А если ситуация - компьютер один, но пользователей два. Например

администратор в фитнес зале. Работают через два дня. У каждого свой аккаунт на CRM. Чтобы исключить подмену куки в данном случае, самый действенный способ - уничтожать их при logout (и давать новые cookie, при логине)? Или дать время жизни - сутки, к примеру?

Так при логауте, у тебя данные сессии пустыми становятся, зачем её пересоздавать?

Насколько помнится при сессии с куками время жизни не ставят(возможно и делают так), но да, при логауте чистится все

Дать время жизни, сотрудник может забыть нажать logout

Тогда не пойму чем плох тот же джвт? (Вопрос не для холивара, а скорее к ТС, мб он нашел для себя сессии более подходящими)

сессиями проще контролировать (например их время жизни) с сервера

Опасный вопрос

Как минимум при смене пароля можно разлогинивать других пользователей сразу

++ поэтому спросил не лучше ли джвт, а в чем причина выбора именно сессий, мб требование к сервису стоит)

Согласен, в случае "проеба" токена, его не кильнешь пока ттл не устареет, либо не ревоукнешь его путем смены пароля)

можно держать блеклист токенов, но во первых надо знать токен, во вторых это уже не совсем stateless будет

Jwt нужен если: 1) ты хочешь дать доступ к стороннему сервису 2) у тебя микросервисы Если нет ничего из этого - используй только сессии

++ фиг с ним с 1м пунктом, 2й пункт теряет смысл джвт)

стороннему сервису по сути похрен какой токен пихать в заголовки запросов к АПИ, там может быть и сессия

А как же 3) доступ к своему фронту? Чтобы тот 1 раз авторизовался и дальше а) перелогинился от юзера б) юзера выкинул, чтобы тот сам повторно вошёл, если это супер-пупер защищенная апп и не нужно без его ведома обновляться?

Какой TTL у такой сессии будет?

Это можно сделать и через сессию

Правда не видел реализацию с сессиями для сторонних сервисов. Обычно джвт либо какие-то ауз токены, как у Амазон, например

а какой TTL будет у токена выдать его вместо сессии? выдадите без ttl токен?

Я и не говорю, что нельзя. Суть отличия сессий от джвт же ведь в стэйтлесс и возможности юзать отдельный ауз микросервис, при этом остальным сервисам достаточно распарсить токен и все (при джвт)

Год, для сессии год это много

у больших сервисов по типу гугла и амазон да но с сервисами по меньше встречаю это очень часто, вместо jwt там просто какой то uuid или какой то еще велосипед

какая разница сесссия не сессия? токен точно так же украсть можно

Фэйсбук вроде 2 токена джвт юзает, шорт и лонг. И требует шорт, чтоб получить лонг

В плане ттл

access_token + refresh_token дефолт вроде

Такая что сессия хранит много информации, и при большом ТТЛ будет много мусорных сессий, которые уже не используются

Там даже велосипеда нет. Видел и применяю местами практику с рандомным (пусть будет ууид) ключом, для идентификации, а чтоб пост запросы делать, требую подпись в заголовке

ну да, тут нельзя не согласится, поэтому и говорю что такое заметил у сервисов на порядок меньше амазона

Да, дефолт такой. Но то что я говорил про фб тут: https://developers.facebook.com/docs/pages/access-tokens/ У них прям шорт и лонг аксесс

Надежнее сессии гораздо, как понял

Хз, как-то гуглил, и нагуглился. В итоге ни в одном проекте не юзаем сессии) все "как у всех" с оауз 2.0 (джвт)

JWT != oAuth 2.0

Каюсь, оауз это все же протокол, а джвт формат токена, но как заметил, в обиходе подмена понятий идёт и т.к. оауз в качестве формата токена обычно юзает джвт, то и под джвт подразумевают большинство, как раз оауз) Если мы про это