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

Значитс так, сделал валидацию токенов с помощью JWT?
Например как написано здесь..
https://habrahabr.ru/post/278411/
или здесь
https://sdqali.in/blog/2016/07/07/jwt-authentication-with-spring-web---part-4/

Приблизительно, какие преимущества мне это дает понимаю. Но возник вопрос.

1. Если jwt токен не хранится в cookies, то где? Ведь мы логинимся, получаем токен, например говорим - этот токен будет жить 1 неделю. А где он хранится чтоб пользователь на сл день включил комп, браузер и с этим токеном работает дальше без повторной авторизации? Вот это как-то непонятно..
2. Получается что, если используется jwt, то на стороне спринга можно отключить CSRF - верно?
3. Где и как генерировать sekret.key? Например здесь и здесь?
http://kjur.github.io/jsjws/tool_jwt.html
http://jwtbuilder.jamiekurtz.com/

Спасибо.

UsmanВ hidden-поле - а как, если фронт отдельно от бекенда? Сервер только для обработки данных. и с фронтом не связан никак.


Usman- Страница осталась открытой (сохранена и восстановлена браузером при открытии)
- В составе URL (токен в GET-запросе) - в моем понятии это уже какие-то грабли. Токен должен передаваться в хедере. Во всех примерах так и делается..

UsmanФронт обязательно свяжется с бэком, например, в процессе аутентификации/авторизации. - да, это я понимаю. Просто Начитался о jwt - думаю трендово. )) Еще в самом начале задавался вопросом, этим. У меня нет ни 150 микросервисов, для которых такой токен - это наверняка хорошо, с таким же успехом можно пользоваться кукисами и сохраниемым там JSESSIONID.

Тогда в данном случае если есть 1 сервер и 1 клиент JWT не дает мне никаких преимуществ...


UsmanПеречислил некоторые варианты передачи. В любом случае клиент получит токен.
Самое важное - безопасность. - ну так передавать как параметр или как хедер, нужно же где-то его хранить. Не вариант - закріть вкладку и снова логиниться...


UsmanИ с этим токеном можно "гулять" по всему сайту? Долгоживущие токены - не безопасны,
особенно в том случае, если сайт содержит важную информацию (документы, или даже
обработка платежей и пр.) - да о этом уже тоже начитался..

UsmanПосмотрите также в сторону https://ru.wikipedia.org/wiki/OAuth. - дык ведь нужно делать или свой сервер или пользоваться чужим, а они не бесплатные...

Petro123Итак, вам по ТЗ нужна аутентификация form сделанная самим App сервером без спринга или в спринге из коробки она же самая. - к этому проекту у меня ТЗ нет, просто хочется сделать как лучше, вот и загорелся, попробовал, а потом проанализировал и понял, что ничего мне это не дает.
Делаю все на спринге, бекенд+Ангуляр потом скорее всего, так что, сервер просто обрабатывает запросы.

Petro123рядом тема:
"Авторизация на сайте" - пасиб, сейчас гляну.

mephПредставьте, что у вас высоконагруженный бекэнд REST и к нему обращаются мильен консьюмеров. Токен хранит информацию о клиенте внутри, соответственно вам не нужно лезть в БД на каждый чих (т.е. вместо двух запросов: авторизация + запрос данных у вас всего лишт один). Как уже заметили, токен не должен жить слишком долго. - Представить могу, но такого не ожидается... Немного не понял про БД. Если делать обычные токены, то можно выставить срок действия например 2 часа и все. Хранить или в менеджере сессий или в кеше.. Я немного не понимаю, - зачем БД?

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

Petro123при первом входе и создании сессии проверить пароль в БД (хеш) и узнать кто входит.
Если список юзверей в БД, туда и лезут. Что тут непонятного? - я думаю, мы немного не поняли друг-друга. При первом входе да, естественно, а если пользователь уже получил сессию, то незачем же... Я подумал, что в ответе имелось в виду, что с каждым запросом нужно будет лезть в БД. Там не было указано, что только с первым..

Petro123Итого вам первый метод - базовая. Но там окошечко от ослика - смешное. И шифрования нет.))))) Вы не поверите, перечитал Ваш ответ 3 раза не понял, на что Вы ответили.. )))
О каком первом методе речь? Вы о просто JSESSIONID?
Окошечко, ослик? ))) Не могу найти параллели.
Зачем метод - form?
Ведь смысл был залогиниться, получить токен и слать нужные запросы к серверу с этим токеном.