Ну ты же писал что куку можно заснифать, а сторадж даже снифать не надо

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

Надо иметь локальный доступ к компу. И что-то мне кажется, что JS имеет доступ только к стораджу того домена с которого этот JS прилетел, а не ко всему в браузере.

У тебя тут проблема в том, что refresh должен обновляться сильно реже access. Ну т.е. не на каждое обновление. Иначе какой смысл в двух токенах?

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

Можно сделать время жизни с "нахлёстом". Т.е. обновлять токены несколько раньше, чем они протухли.

Но у тебя нет особого выбора, если мы говорим про браузер.
Если клиентом у тебя выступает какой-то сервис, который ты пишешь, то да, refresh слать каждый раз не надо.

refreshToken - одноразовый, да обновляется заранее, но если его уже использовали то всё.

Одноразовость это один из подходов. Он не единственный.

В общем, тут главный вопрос: какую проблему ты решаешь?

Надо сделать двух-фазный коммит. Пока клиент не придёт в бекенд с новым токеном - старый рефреш-токен не удалять до конца срока его жизни. 😊
Хотя... теряется смысл быстрых токенов - придётся проверять на каждом запросе наличие в базе "полуживых" рефрешей.

jwt же не про  доступ к сайту а про выдачу ключей и ключи эти могут быть использованы в N различных и, возможно, совершенно не связанных сервисах/организациях, объединяет их лишь "центр выдачи" куда мы и ходим с refreshToken за новым ключем.
поэтому считаю совершенно вредным везде рассылать refreshToken.

по поводу одноразовости - да, можно его использовать на всем сроке жизни и менять только перед протуханием, но это не отменяет возможность прихода 10 вкладок в момент необходимости смены refresh на новый.

Про вред рассылки я не понял.   🙁

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

я про то, что если мы идем за дынными на какой-нибудь GET /basket/list-items то в запросе достаточно accessToken чтобы идентифицировать юзера и не надо в запрос класть refreshToken.

Проблема десяти вкладок решается установкой куки с новым access-токеном, до экспайра предыдущего. Refresh-токен в этом не участвует.
Нет особой проблемы выпустить несколько разных access-токенов в случае гонки.

А вредность-то в чём?

Отсутствие необходимости не означает наличие проблем.

Я больше скажу… За временем жизни refresh-токена на беке можно следить и фоново его обновлять. Фронт вообще об этих токенах может ничего не знать.

для случая "общий на все вкладки одноразовый refreshToken " и "каждая вкладка имеет свой accessToken" возможна ситуация:

1. вкладка X заблаговременно (за 10 минут) идет за новой парой refresh + access
2. бэк выдает новые токены, старый refresh удаляет из БД.
3. Браузер делает setCookie для refresToken и вычитывает в память значение нового accessToken
4. вкладка Y заблаговременно (допустим, через 10 секунд после вкладки X) идет в бэк но в запросе у неё не новый refrestToken а тот, с которым ходила вкладка X
5. Вкладка Y получает 401

в итоге в куках лежит старый refreshToken - браузер на шаге 3 не сделал setCookie.