а httponly

Привет, @llamakarl,  у нас принято представляться и кратко рассказывать о себе с тэгом #whois.

Cпасибо за внимание!

Вакансии размещаем тут: http://t.me/jobsit52/2

Лучше не хранить accessToken в куках, только в памяти приложения, чтобы при закрытии последнего токен терялся и, при следующем запуске приложения ему необходимо было идти на бэкенд за новым токеном.
Для получения же нового токена как раз нужен refreshToken, который уже  хранить в куках secure+httponly.

От выдачи 10 новых токенов при 10 параллельных запросах частично спасает инвалидация и выдача нового refreshToken каждом запросе - кто первый пришел, того и токен.

согласен

вот по этому я написал что Г решение было

ну частично

вообще я делала ещё вариант с хранением в базе как сессию, для разных приложений что-бы была возможность отозвать

но там токен жил пол года)

попа-боль вам расскажу в тему обновления refreshToken + accessToken.

вот выдается у нас на каждый запрос обновления токена новые refreshToken + accessToken, а что делать если пришло сразу 10 запросов с одним и тем же refreshToken?? Правильно отдаем первому новую пару accessToken + refreshToken  а всем остальным ошибку "неправильный refreshToken" ну и код какой-нибудь о том, что он должен попробовать ещё разок, ведь наверняка браузер уже выставил в куках нужный токен из 1го запроса и все остальные 9 вкладочек могут попробовать ещё разок.... потом 8, 7 ... в итоге ряд сходится...

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

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

причем случиться этот "браузер не сохранил" могло как через пару дней так и через 5 минут.

Вторая цель создания рефреш-токена - он редко летает по сети, и значит меньше вероятность его перехватить. Если же положить его в куки - тогда он в каждом запросе к бекенду будет летать. Негоже так. Надо его в Storage класть, а не в куки.

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

ну, тут зависит от бэка, можно же настроить domain + path.

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

а что ты имеешь ввиду под storage? localStorage и sessionStorage, которые через инструменты разработчика и жаваскрипт видны?

Ну какой-то Storage в браузере, который не куки. Типа локальной базы данных.

его видно из JS а это большой такой, жииирный минус.

Они доступны из js, т.е. подвержены целому классу атак.

Если тебе на сайт сумели подсадить левый JS, то onlyhttp куки тебя уже не спасут

расширения браузера тут ещё играют роль