Почему в каждом первом проекте/туториале для защиты JSON API используется JWT? Почему вместо JWT не

Почему в каждом первом проекте/туториале для защиты JSON API используется JWT? Почему вместо JWT не используются сессии?

>>324778625 (OP)
>Почему вместо JWT не используются сессии?

Сессии сложнее по архитектуре в простейшей реализации..
Для сессий тогда придётся в туториале делать курс по установке БД и так как курс про Security механизмы, то по нормальной настройке БД по хранению данных сессии, а если курс на что-то претендует, то там много придётся разжевывать по БД и как секьюрно всё это работать должно, какие-нибудь сертификаты нужно будет выпускать, на этом моменте 90% новичков просто сдохнет и сам автор курса.
Ягодкой сверху будет то, что БД не ставят на систему в таких случаях, а в докере, т..е придётся ещё докер разжёвывать.
Ну можно, конечно, в файл на сервере писать или SQLite, но тоже такое себе, несерьёзно для курса.
JWT, в простейшей реализации, ты просто высираешь его на клиент и клиент его хранит у себя в кукисах или локальном хранилище, вся инфа клиента в токене, твой сервер ничего не хранит, простейшая архитектура для туториала. Усложнение архитектуры, по аналогии с сессией, начинается когда ты начинаешь делать отзыв токена.

>>324778625 (OP)
Спроси у любой нейросети, она пояснит.

>>324779667
>Сессии сложнее по архитектуре в простейшей реализации.
В чём это выражается?

>Для сессий тогда придётся в туториале делать курс по установке БД
Зачем? Сессии хранятся в памяти. Буквально в мапе.

>>324778625 (OP)
на самом деле это просто модно
реальных профитов нет, если разобраться

>>324779667
>БД не ставят на систему в таких случаях, а в докере

Имел в виду, что в случае туториала, ибо засирать машину пользователю БДшкой точно нет смысла.

>>324779884
>В чём это выражается?

JWT это перекладывание хранения на клиента, а сессия это всегда хранение на сервере + выше нагрузка на сервер, так как ты каждую сессию проверять постоянно будешь.

>Зачем? Сессии хранятся в памяти. Буквально в мапе.
Ну такое себе, даже для туториала не особо.

>>324778625 (OP)

Situations Favoring JWTs:

Microservices Architectures:
Where multiple independent services need to authenticate users without a shared, centralized session store.
Single-Page Applications (SPAs) and Mobile Apps:
Which often benefit from stateless authentication and can easily handle token storage and transmission.
API-First Designs:
Where the focus is on providing a secure and scalable API for various client applications.

Considerations for Sessions:
While JWTs offer significant advantages in modern architectures, session-based authentication remains a valid and often simpler choice for:

Monolithic Applications:
Where centralized control over user authentication and state is easily managed.
Applications Requiring Immediate Revocation:
Sessions can be instantly invalidated on the server, which is more complex with JWTs unless a revocation list is implemented.
Applications Handling Highly Sensitive Data:
Where the added security layer of server-side session management might be preferred.

In essence, the choice between JWTs and sessions hinges on balancing scalability, architectural complexity, and specific security requirements.

>>324780192
>JWT это перекладывание хранения на клиента, а сессия это всегда хранение на сервере + выше нагрузка на сервер, так как ты каждую сессию проверять постоянно будешь.

Ты уверен что эта нагрузка будет хоть сколько нибудь существенной для 99.9% приложений?

>Ну такое себе, даже для туториала не особо.

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

>>324778625 (OP)
Потому что проще печенькой временной бросить в клиента, чем ебать себе голову по секьюрному подключению пользователя.

А можно просто кейклок использовать?

>>324779667
>Ягодкой сверху будет то, что БД не ставят на систему в таких случаях, а в докере, т..е придётся ещё докер разжёвывать.
Схуяли обязательно докер? Поставить бд просто себе на машину религия запрещает? Выдумал проблему из ничего.

>>324781907
А может ещё отдельные микросервисы для операций сложения и вычитания развернуть?

>>324778625 (OP)
Сессии уже устаревший кал. Щаз почти всё сделано на REST, а этот архитектурный стиль предполагает стейтлесс между серваком и клиентом. JWT токен позволяет этого добиться + он проще в реализации требует меньше затран по ресурсам. Даже если мы делаем хранилище публичных ключей, это все равно дешевле, чем открывать и закрывать сессии.
мимо жаба разраб 12 ебаных лет в этой параше

>>324782238
сделай это Пожалуйста.

>>324782256
Ты умный человек. спасибо.

>>324782256
>Сессии уже устаревший кал

Почему?

>Щаз почти всё сделано на REST

Нахуя?

>>324782793
>Почему?
Потому что в современных системах никто не ходит напрямую с фронта в бэк. Плюс у тебя бэк имеен несколько инстансов, а перед ними стоит гетевей в виде Nginx или какой-нибудь другой параши, которая по раунд робин запросы распихивает. Хранить сессии банально неудобно. А токен в хедере запроса самое то.
> Нахуя?
Потому что это очень просто и удобно. Любая макака разберется.

>>324782793
>Нахуя
Если у тебя простой монолитный интернет-магазин с одним сервером, то не нахуя, просто так, каргокультизм, большие дяди из бег-теха статейки умные писали, и ты выбрал.

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

>>324782910
РЕСТ подразумевает слоистость. Проверяй логин-пароль на слое до балансера. Токены тоже часто не на конечном сервисе проверяют.
>>324782256
Про меньше затрат - пиздеж. Стейтлесс можно поддержать и с бейсик аутентификацией.

>>324781906
А токены секьюрным соединением не надо шифровать? Их по-твоему хакер не сможет использовать и так же обновлять бесконечно, пока не заметят?

>>324783008
А для ИДП не нужен отдельный сервачок?

>>324783403
РЕСТ подразумевает слоистость. Проверяй логин-пароль на слое до балансера. Токены тоже часто не на конечном сервисе проверяют.
Да пофиг на проверку логина и пароля. Тут речь про сессии vs jwt.
>Про меньше затрат - пиздеж. Стейтлесс можно поддержать и с бейсик аутентификацией.
Как это ты будешь держать сессию и при этом не будешь хранить данные клиента?
Алсо про меньше затран - не пиздеж. Вместо того, чтобы потоки занимать удержанием сессии, ты просто открываешь ключем данные из JWT, что намного дешевле.

>>324783801
Ок, сессиия правда нарушает стейтлесс, но ты можешь делать рест по данным и хранить стейт по метаданным, жопа не отвалится.
Сессия не занимает никаких потоков, это не коннекшен, а набор данных с айдишником.

>>324783903
Ну вообще согласен.

>>324783558
Как он у тебя будет их обновлять, если приватка у тебя на бэке лежит и генерит эти хеши?

>>324781986
Засирать систему не надо только для обучения, адекватные люди докер используют локально

>>324781906
>ебать себе голову по секьюрному подключению пользователя.

А при передаче JWT тебе не нужно устанавливать секьюрное соединени?

>>324785947
Какие хеши?

>>324785947
рефреш токеном, если его тоже спиздили

>>324786861
JWT токен это по сути своей хеш в который ты можешь шифровать чо угодно.

>>324787128
>JWT токен это по сути своей хеш в который ты можешь шифровать чо угодно.

Что блять? А как сервер понимает что JWT токен валидный если это хеш?

>>324787689
По секрету, очевидно же.

>>324788097
Очевидно, что стоит говорить, что JWT токен это хеш, если он получается не через пременение хеш функции, а через кодирование.
Хешем является лишь последняя часть - подпись.

>>324785979
Нашел над чем трястить.

apt-get remove
brew remove

И прочее для кого придумано? Или ты у мамы умный, качаешь сорцы и сам компилишь?

>>324788097
А откуда он берёт этот секрет?

>>324788411
секрет)