В новых проектах есть смысл использовать cookie или достаточно все заменить JWT?

Question

[ivandao]

В новых проектах есть смысл использовать cookie или достаточно все заменить JWT?

Comments

[Алексей]

А токен храниться где будет, не в HttpOnly куках ли?

[ivandao]

slide13, на клиенте в localStorage, на сервере в БД (или в памяти), передаваться в body.

[Алексей]

ivandao, не надо хранить токен в localStorage

[ivandao]

slide13, в куках лучше?

[Алексей]

Только в httpOnly, кторые придут с сервера. Соответственно, на фронте не будет никакого доступа к ним, что частично решает проблему их кражи. А еще лучше использовать что-нибудь типа OAuth с access и refresh токенами.

[bro-dev]

slide13, httpOnly куки ставятся только при загрузке страницы, а значит их не поставить без перезагрузки, учитывая что jwt будет в spa приложении про куки можно забыть.

[Алексей]

bro-dev, что простите? httpOnly куки можно сетить в любом респонзе. Без всякой перезагрузки в реакте все работает. После получения респонза с куками следующие реквесты отправляются уже с этими куками.

Answer 1

[Robur]

Смысл есть. Но может быть и достаточно заменить на JWT.
от проектов зависит.

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

Comments

[ivandao]

В каких случаях токенной авторизации будет недостаточно для обеспечения безопасности, удобства, других требований?

[Robur]

например когда сервер сам создает и держит сессию, и идентификатор сессии хранится в http-only куках.
Ну или еще какие-то данные туда складывает.
Или когда нужно как-то пометить не xhr запросы.

[ivandao]

Robur, тут в интернетах предлагают в заголовке X-CSRF-Token передавать токен, можно ли это использовать?
А то заголовок Cookie принуждает браузер хранить эту информацию, а это может быть небезопасно.

[Robur]

ivandao, Я не очень понимаю какую проблему вы пытаесь решить и какой ответ ищете.
Использовать можно все - кто ж вам запретит.

[ivandao]

Robur, хочу уйти от использования куков.

[Robur]

Это не проблема - это желание. Уйти вам никто не запрещает - уходите, если хотите.

Answer 2

[Александр Филиппенко]

Вы путаете способ авторизации, со способом хранения токена.
В куках можно хранить как ключ сессии, так и JWT токен. Их любой из них можно хранить в localStorage (но не нужно по соображениям безопасности).
Что использовать, решать вам, плюсы и минусы есть и там и тут.
Я считаю оптимальным хранить ключ сессии в httpOnly cookie, а сами сессии в Redis. Но тут есть пространство для холивара)

Comments

[ince]

А в sessionStorage?
Чем генерить ключ сессии? Если я этот ключ передаю по http (без ssl)(таково условие задачи), то его можно перехватить? Как можно зашифровать?

[Александр Филиппенко]

ince, если данные идут без шифрования значит их можно перехватить, тут ничего не поделать. И шифровать идентификатор сессии смысла нет, ибо пароль с логином так же могут быть перехвачены.
Генерить на бэке любую уникальную строку, есть всякие разные стандартные библиотеки, но если ими не пользоваться, то проще всего взять uuid.

[ince]

Александр Филиппенко,

ибо пароль с логином так же могут быть перехвачены.

Их можно как минимум захэшировать

[Александр Филиппенко]

ince,

Их можно как минимум захэшировать

То есть алгоритм хэша будет виден на фронт? Ну лучше чем ничего, но такое себе всё же.

А упомянутый выше OAuth

Это хороший метод когда нужно из приложения авторизоваться в другом приложении. А если из браузера, то не вижу особого смысла. Всё равно OAuth токен надо где-то хранить, а надёжнее куков в браузере ничего нет.
И на бэке надо определять по OAuth токену что это за юзер, а это уже похоже на сессию)

[ince]

Александр Филиппенко,

алгоритм хэша будет виден на фронт

Код обфусцирован, ничего не видно