Интересно полюбопытствовать кто как организовывает аутентификацию/авторизацию (в частности для веб-приложений)

1) куки + сессии + какой-нить мемкеш/редис для сессий?
2) модный JWT, хранение его в localStorage (боже упаси О_о) access/refresh токены и все дела?

(ко второму у меня претензия в том, что в случае с первым мы можем юзать http-only куки и их не так и просто старабанить), тогда как во втором случае это легко воруется любым встроенным скриптом, левым экстеншеном в браузере и т.д.

jwt этож ваще страх, я за первый вариант

При должной мотивации ни первый, ни второй способ сам по себе не защитит от взлома

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

Но ведь с первым будет чуточку сложнее если мы используем httpOnly куки
просто так их не прочитать если даже инжектить левый скрипт, да и браузерными екстеншенами тоже (чуточку усложняет процесс)
Хотя вот на счет последнего не уверен, Есть ли возможность у екстеншена читать httpOnly куки по урлу (особенно, если юзер на свою голову еще и одобрил пермишны для екстеншена)

А почему не желательно хранить токен в localStorage? Даже если его модификуют, то не пройдет же проверка на сервере

JWT нужен, если тебе не нужны индивидуальные операции над пользовательскими сеансами, для всего остального - сессии

а зачем его модифицировать, если его легко скопировать и перехватить?
У меня больше вопрос вызывает то, как легко его “перехватить”, например, сторонним встроенным скриптом или вредоносным екстеншеном браузерным

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

а что имеется ввиду под индивидуальными операциями над пользовательскими сеансами?)

К примеру отправить пользователя в бан на пару минут, или статистику собирать

Дело в том, что "чуточку сложнее" это не значит, что безопасно. Если вам нужна безопасность, то вам надо решать проблему не где хранить, а как обнаружить попытку взлома.

я просто скорее пытаюсь понять целесообразность JWT для конкретно веб приложений и SPA.
Для остального - нормально.

А в этом случае много вопросов к безопасности. Хотя, если микросервисы крутятся в одной доменной зоне, скажем, *.domain.com, тогда можно на каком-нибудь login.domain.com при аутентификации засылать куки на всю доменную зону и все остальные микросервисы будут легко “опознавать” героя картины.

@deusiudex да.. это тонкое замечание, спасибо

@m03geek ну это само собой тоже. Мне больше интересно защититься, скажем, от “глупых” попыток перехвата.

Тот же jwt вполне себе секурно можно использовать. Получил jwt со сроком жизни 2-3с, использовал его для установки вебсокет соединения и всё.

JWT в принципе же имеет смысл только в паре с refresh токеном, чтобы его обновлять каждые сколько то минут/секунд.
Иначе он не имеет смысла

Собственно, мне интересно подискутировать целесообразность этого подхода для веб приложений и SPA в частности, потому как мне пока с трудом видится эта целесообразность

Разные домены апи, ограничения на количество логинов, синхронизация состоянии и тд. jwt без рефреш токен  зачем так делать?

Да, согласен
Это актуально для oauth2, для публичного 3рт пати апи и прочее прочее.

Но конкретно для spa/фронта веб приложения, на мой скромный взгляд, это пока бессмысленно.
Классические сессии самые надёжные (хотя и более требовательные к инфраструктуре)

А если к спа добавить мобильный клиент? Конечно зависит от приложения если 100% апи  только на спа то можно и куки

ну мобильный клиент это другое дело, там я согласен
(ну если под мобильным клиентом подразумевается типа ionic или другое веб-вью решение)
А я вот хотел поговорить именно об обычных браузерных SPA/фронтендах

А нужны ли обычные спа вот какой вопрос меня начал мучить) вижу часто контентные ресурсы и вообще лендинги по сути как спа делают.CRM  как спа это понятно смысл а вот  блог нет... ( как пример)