Как вы делаете jwt аутентификацию в server-side react приложении?

Question

[Islam Ibakaev]

Куда вы помещаете токен, отправляемый сервисом авторизации(например aws cognito) в localStorage, в cookie?
Какие шаги предпринимаете, чтобы защититься от Cross-Site Request Forgery, Man-in-the-Middle, Cross-Site Scripting атак.
Насколько мне известно подобная система аутентификации менее подвержена XSRF атакам, поскольку браузер при запросах не устанавливает Authorization token в заголовке запроса автоматически.
Однако эта система более подвержена MITM и XSS атакам чем session-based auth система.

В общем вот я залогинился и получил токен от aws cognito.

Учитывая, что приложение делает первичный рендеринг на сервере (server-side rendering), какие шаги применить дальше(типа best practices)?
Не могу найти в инете состоявшегося паттерна для кейса server-side react app + token - based authentication?
Если вы уже делали нечто подобное поделитесь опытом, дайте ссылку на репозиторий, на какой-нибудь туториал. Или хотя бы пошагово объясните как сделать, какие детали учесть? Вообщем хоть чем-нибудь подсобите.

Answer 1

[Ilkon]

Поделюсь своим решением. Хотя у меня на сервере стоят рельсы, а реакт только на морде. Но тем не менее, вдруг будет полезно.

При авторизации сервер генерит:
- access token
- cookie
- refresh token
которые затем гоняются между клиентом и сервером.

Refresh token может отсутствовать. Вообще говоря он нужен только для обновления access token, и клиент добавляет его в запрос только когда истекает срок действия access token. В этом случае сервер генерит новый access и refresh token.

Cookie отдается с пометкой HTTP only, то есть клиент их прочитать никак не может. Cookie нужны только для проверки валидности access token, то есть никаких сессий по ним нет (вообще приложение полностью stateless).

Оба токена (access и refresh) клиент хранит в local storage, откуда извлекает их для каждого запроса на сервер.

Любой запрос от клиента, содержащий валидный access token, считается авторизованным, только если в нем есть соответствующие токену куки (не совпадающие, а соответствующие, то есть закодированные по какому-то алгоритму с access token в качестве базы). Ну и если есть refresh token, то также смотрим, подходит ли он к нашему access token.

Такая схема, в совокупности с HTTPS, неплохо защищает от XSS или от CSRF уязвимостей (оговорка: но не от обеих сразу).

Немного теории, почему это работает, можно прочитать здесь: www.redotheweb.com/2015/11/09/api-security.html

Comments

[davidnum95]

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

[Islam Ibakaev]

у нас на бекенде aws. то что ты написал ляжет на плечи api gateway сервиса(если я не ошибаюсь). а он будет проверять соответствует ли токен в куках токену, передаваемому в Autorization заголовке?

[Islam Ibakaev]

на ком вообще лежит ответственность за безопасность системы: на фронтендщике или бекендщике? Просто я на фронте.

[Islam Ibakaev]

Ilkon то есть злоумышленник, похитивший токен, сделав запрос на апи ничего не получит ибо на сервере будет проверяться соответствие токена в заголовке токену который в куках. У злоумышленника в куках токена не было, поэтому ничего у него не выйдёт. А если он поместит токен в куки и уже потом сделает запрос, тогда получается что всё у него прокатит?

[Ilkon]

davidnum95: Нет. Если человек авторизовался с другого браузера, то для него генерится новый access token. Вместе с ним создается новый refresh token и новые куки, которые и отдаются этому браузеру.
Старые куки и старый токен при этом продолжают работать.

[Ilkon]

Islam Ibakaev: "А если он поместит токен в куки и уже потом сделает запрос, тогда получается что всё у него прокатит?"

Я собственно поэтому и сделал акцент на этом:
"Любой запрос от клиента, содержащий access token, считается авторизованным только если в нем есть соответсвующие токену куки (не совпадающие, а соответствующие, то есть закодированные по какому-то алгоритму с access token в качестве базы)."

То есть в куках мы записываем не тупо access token, а например, другой JWT-токен, у которого в payload стоит md5-хэш от access token. Поскольку этот токен подписан на сервере, то подделывать его бесполезно, и подмена его на access token ничего не даст.

[Islam Ibakaev]

Ilkon: звучит интересно, но не до конца понятно, может скините каку-нибудь статью или может видео, расширяющие эту тему.

[Islam Ibakaev]

Ilkon: и что насчёт aws api gateway? пользовались ли вы? будет ли он делать описанную вами в ответе провеку?

[Ilkon]

Islam Ibakaev: Так ссылку на статью я же привел в ответе.
Сам код показать не могу к сожалению.

[Ilkon]

Islam Ibakaev: Нет, AWS API Gateway не пользовался.

[Islam Ibakaev]

Ilkon Правильно ли я понимаю, что получив токен на клиенте, я должен достать некий md5-hash из токена(не совсем понятно как это сделать, подскажите) и указать его в качестве payload новосозданного токена, помещённого затем в куки. И почему это должно прокатить. Не может ли злоумышленник провернуть всё то же самое(или для него это будет слишком сложно)?
p.s. если какой вопрос показался глупым, извиняйте, я просто пытаюсь понять как всё это должно работать)

[Ilkon]

Islam Ibakaev: Нет, неправильно.

Как я уже написал, сервер передает клиенту куки с пометкой HTTP only. То есть клиент их вообще никак не трогает. Они хранятся во внутреннем хранилище браузера, куда клиенту доступа нет. Но если клиент посылает запрос на сервер, то браузер эти куки включает в запрос, автоматически.
Куки нужны только затем, чтобы удостовериться, что access token не украден (если кто-то его украдет и попытается зайти на сервер с ним, то куки он все равно своровать не сможет - именно для этого у них стоит флаг HTTP only).

Вообще клиент с токенами практически не работает. Задача клиента проста - если сервер авторизовал запрос и вернул пару токенов, то надо эти токены сохранить, и включать их в последующие запросы к серверу (оба, или только access token). Всё! Вся забота о валидности токенов, проверка на соответствие токенов кукам и т.п. -- это головная боль сервера.

[Islam Ibakaev]

Ilkon: спасибо! многое стало понятным!

[tamtakoe]

А зачем вам, вообще, токены в local storage? Можно же использовать access и request token в cookies и X-XSRF-TOKEN, чтобы защитить куку от CSRF. Защищенность будет такая же как у вашего способа

[Islam Ibakaev]

tamtakoe, вы издеваетесь? я это вопрос задал в марте прошлого года

Answer 2

[Иван]

От MitM вас защитят только SSL сертификаты и иконки на сервере.
Где хранить? Ну вообще это не так важно, но я бы хранил в LocalStorage. Хз почему, просто левая пятка говорит.
Хотя если у вас не совсем REST, то можно хранить токен в кукисах и отправлять "по классике" (в заголовках).

Comments

[Алексей Ярков]

в какая

[Иван]

Алексей Ярков: проклятая автозамена...

[Алексей Ярков]

Иван:

[Islam Ibakaev]

Иван: какие меры предпринимаешь для защиты от XSRF атак?

[Islam Ibakaev]

Иван: что значит не совсем REST. использование или неиспользование cookie не влияет на RESTфульность API. Не предумывай.

[Иван]

https://ru.wikipedia.org/wiki/REST#2._.D0.9E.D1.82...
Т.е. на клиенте может куки и есть, но используются они не по прямому назначению, т.к. на сервере кукей нет.

[Иван]

Islam Ibakaev: Если скрипты ваши, то следите за ними :) Опять же SSL в помощь.
Для защиты внешних скриптов есть атрибут 'integrity', рекомендую почитать.