Только в httpOnly, кторые придут с сервера. Соответственно, на фронте не будет никакого доступа к ним, что частично решает проблему их кражи. А еще лучше использовать что-нибудь типа OAuth с access и refresh токенами.
slide13, httpOnly куки ставятся только при загрузке страницы, а значит их не поставить без перезагрузки, учитывая что jwt будет в spa приложении про куки можно забыть.
bro-dev, что простите? httpOnly куки можно сетить в любом респонзе. Без всякой перезагрузки в реакте все работает. После получения респонза с куками следующие реквесты отправляются уже с этими куками.
Смысл есть. Но может быть и достаточно заменить на JWT.
от проектов зависит.
Если ваш вопрос на самом деле был в том что "не устарели ли куки, и не стоит ли перестать их использовать в угоду токенной авторизации" - нет, не устарели.
например когда сервер сам создает и держит сессию, и идентификатор сессии хранится в http-only куках.
Ну или еще какие-то данные туда складывает.
Или когда нужно как-то пометить не xhr запросы.
Robur, тут в интернетах предлагают в заголовке X-CSRF-Token передавать токен, можно ли это использовать?
А то заголовок Cookieпринуждает браузер хранить эту информацию, а это может быть небезопасно.
Вы путаете способ авторизации, со способом хранения токена.
В куках можно хранить как ключ сессии, так и JWT токен. Их любой из них можно хранить в localStorage (но не нужно по соображениям безопасности).
Что использовать, решать вам, плюсы и минусы есть и там и тут.
Я считаю оптимальным хранить ключ сессии в httpOnly cookie, а сами сессии в Redis. Но тут есть пространство для холивара)
А в sessionStorage?
Чем генерить ключ сессии? Если я этот ключ передаю по http (без ssl)(таково условие задачи), то его можно перехватить? Как можно зашифровать?
ince, если данные идут без шифрования значит их можно перехватить, тут ничего не поделать. И шифровать идентификатор сессии смысла нет, ибо пароль с логином так же могут быть перехвачены.
Генерить на бэке любую уникальную строку, есть всякие разные стандартные библиотеки, но если ими не пользоваться, то проще всего взять uuid.
То есть алгоритм хэша будет виден на фронт? Ну лучше чем ничего, но такое себе всё же.
А упомянутый выше OAuth
Это хороший метод когда нужно из приложения авторизоваться в другом приложении. А если из браузера, то не вижу особого смысла. Всё равно OAuth токен надо где-то хранить, а надёжнее куков в браузере ничего нет.
И на бэке надо определять по OAuth токену что это за юзер, а это уже похоже на сессию)
Средний
