JWT и извращенцы

jwt для аутентификации, а не для авторизации

Ну так, а я от него что прошу?

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2...

ну, а ишьюить сделанную ранее аутентификацию то зачем?

Чтобы отозвать, например. Пользователь что не имеет права «разлогиниться» до конца действия токена?
Офкорс, я могу изменить ключ для инвалидации всех токенов, но это не вариант.
Так что похоже классические сессии мне больше подходят.

разлогиниться это синоним «разавторизоваться».
и то, как ты это реализуешь, никоим боком не касается jwt.

jwt он про другое.
jwt про аутентификацию json-а, который в нем лежит.
другими словами, проверив подпись, ты гарантируешь что json аутентичный.

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

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

куку подписывают как попало и кто как захочет.
здесь же единый вменяемый стандарт.

по поводу хранилища и того что туда нужно ползать — вопрос лишь того, как ты организовал сессионность и авторизацию.

разлогиниться это синоним «разавторизоваться».

лiл

сформулируй «разлогиниться» в терминах авторизация и аутентификация, как ты его понимаешь

такому сессионному йд ты можешь доверять, тк он атуентифицирован твоей подписью.

Лол.

Смотри ссылку выше, что ли.

он недоумевает зачем нужен jwt, когда у него есть подписные куки.

jwt, как и подписные данные куки — «method for representing claims securely between two parties».

только куки каждый подписывает как ему вздумается, и именует как ему понравится.

jwt же стандартизирован.

разница только в этом.

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

sign out для слабаков. Бан юзера, смена пароля

это как бы не задача токена, хочешь - засовываешь в данные к токену счетчик (long) который хранишь в базе, инкрементишь при смене пароля, бане и т.п. - вся твоя мила потребность этим и решается, при валидации токена смотришь если значение не равно тому что в базе то все - пока.

если значение не равно тому что в базе

В чем смысл токена если нужны постоянные обращения к базе?

если значение не равно тому что в базе то все - пока

Так этим ты инвалидируешь все токены пользователя, на всех устройствах.

В чем смысл токена если нужны постоянные обращения к базе?

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

на всех устройствах.

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

Причем тут кеш. Тебе все равно нужно куда-то обращаться, что как бе сводит на нет все преимущества от селф контейнед токена. И да, все данные ненужны.
С таким же успехом я могу просто использовать сессии в in-memory cache, при этом я могу его так же отозвать.

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

А с сессиями такой проблемы не будет.

Тебе все равно нужно куда-то обращаться, что как бе сводит на нет все преимущества от селф контейнед токена.

вообще то он не для того чтобы лентяи в базу/кеш не лазели 8)

А с сессиями такой проблемы не будет.

так используй свои сессии, зачем ты взял какюто херню и просишь чтобы тебе доказали что она в твоем случае нужна?

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

Я хочу таки выяснить в каких случаях их используют.
примеры про общение двух сервисов.

т.е. ты знаешь для чего их используют но продолжаешь хотеть это выяснить? 8)

Нет не знаю. Расскажи зачем оно в SPA если оно не заменяет сессии никоим образом.

Расскажи зачем оно в SPA

JWT и извращенцы (комментарий)

зачем ты взял какюто херню и просишь чтобы тебе доказали что она в твоем случае нужна?

this

Ясн 🐔

не петушись, просто ты лузер и даже не осилил википедию 8)

Куда уж мне до икспертов использующих JWT везде, даже если они нужны в 1% веб приложений.

до икспертов использующих JWT везде

о а чо в это треде есть такие? покаж ка

В чем проблема не совсем понятно.

JWT можно рассматривать как некий контейнер («закодированный» при необходимости) со свойствами (расширяемыми) и в общем правильно уже сказали - стандартизирован.

Хотя, бесспорно есть избыточные вещи. Наверное в нем проще реализовать интеграцию с авторизацией различных сервис-провайдеров...

Примеров полно.

Выглядит удобным, когда необходимо общаться (сессионно) по всяким RPC/REST чем городить всякие велики.

То что ты хочешь нарушает принцип stateless сервера, тебе нужны обычные сессии. Я вот сейчас делаю при каждом обращении к апи из токена достаю id, по нему вытаскиваю из базы пользователя и в зависимости от действия валидирую, в текущем проекте такой подход оправдан, обращения нечасты, лишние несколько микросекунд обращения к базе не принципиальны, зато можно выдать токен надолго, а при компроментации просто заблокировать пользователя. Можно было бы обойтись без jwt, но он есть из коробки во фреймворке, почему не воспользоваться.

в чем смысл мозгов девелопера если он не знает про кеш?

В чем смысл кэша, если бд достаточно быстра?

бд достаточно быстра?

что правда вызов быде на соседней ноде через сеть быстрее локального словаря?

Нет, через сеть врядли, если бд локальная и вся в памяти - вполне.

бд локальная и вся в памяти - вполне.

воу, и часто такое у ваших веб сервисов в продакшене?

Почему нет? Нужно выбирать решения наиболее подходящие ситуации, а не руководствоваться исключитльно усреднёнными правилами, я считаю.

Почему нет?

Почему ты не ответил на вопрос?

Для примера два схожих сервиса в работе: серверная часть занимается хранением данных, валидацией и иногда сохранением результата вычислений, вычисления на клиенте. Пользователей 100-500, размер бд - несколько мб, в крайнем случае потеря данных за пару часов не критична. БД встроенная, ин-мемори, хранит в json, клиенты vuejs, electron, cordova. Ты конечно можешь сказать что это хипстота и ненужно, но т.к. это ПО сильно упрощает бизнес процессы компаний, просто в разработке и сопровождении, я позволю себе с тобой не согласиться :)

Фактически сервер и играет роль сетевой бд для клиента. Такая архитектура востребована во многих ситуациях.

в продакшене?

размер бд - несколько мб

вопросов больше нет

Пфф, нечего сказать? Я не говорил что так нужно делать всегда, а то что в определённых ситациях вполне себе можно. Пускай это будет 1Гб, что это принципиально изменит?

Пфф, нечего сказать?

мнеж придется опуститься до твоего уровня где ты уже задавишь своим опытом

если он не знает про кеш?

И мы снова пришли к вопросу «как разлогинить пользователя, если в кэше он залогинен»!

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

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

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

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

ps. ребята которые варят такую кухню не будут спрашивать на форуме зачем нужен JWT и т.п. потому разберутся сами

Именно все так и есть. Я сам из приложения выпилил почти всю функциональность с токенами и рефреш-токенами (не я ее реализовывал), использую только для гоняния «горячей» информации, а именно роли, айди и другой хрени, которая не меняется. Дело в том, что в моем приложении необходима возможность немедленно деактивировать или удалить юзера. Я не стал ничего изобретать и просто на каждый запрос (да, это спа приложение) выбираю юзера с датабазы и смотрю не удален или деактивирован он. Конечно, выходит так, что пока страница загрузится, юзер проверится раз 15, но пока проблем не создает.

Можно не проверять всякий раз в БД, а просто записать в сессионный файл признак один раз, потом проверять при каждом обращении.

что пока страница загрузится, юзер проверится раз 15

срочно надо менять архитектуру

селфконтейнед
ишьюить
Офкорс

Вы серьёзно?

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

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

если это какойнить вордпрес с лапшой на жквери — тут можно положиться на пхп-шную и браузерную магию поверх кук.

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

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

но я понимаю что «у нас не так», «тут все сложнее» и «в реальном мире это не работает» - т.к. по опыту знаю такие банальные вещи не постижимы для рядовых девелоперов