refresh используется только для обновлении access когда аксес протух

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

вот предположим перехватили ваш запрос с acces_token
получается злоумышленник будет иметь возможность имитировать вас до того как кончится этот access_token, тогда ему нужен будет refresh_token

а refresh_token не было в перехваченном запросе => на 1 меленький шаг выше защита

во, дело касается безопасности

Если вы желаете обеспечить безопасность, то используйте именные клиентские сертификаты. Остальное просто самообман

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

а какие у вас еще варианты кроме LS?
вы же не описываете свой бекграунд проекта

бэк на Джанго,

ну есть один httpOnly

что значит бэк?) у вас токен для того, чтобы бэк вас мог опознать, соответственно нужно хранить где-то вне бека

это как сказать, что хранить ключи от квартиры в квартире

Обычно исходят из того, что токены не из запроса крадутся.
Иначе не важно, как они там отправляются, в отдельном заголовке, в теле, в куке — всё это части запроса.
Если вы считаете, что у вас TSL скомпрометирован, то у пользователя уже пароль скомпрометирован.

@rafail_mamedov зато так их не украдут

LS не отправляется

ну да, лучшая защита это отсутсвие входа)

ну надо смотреть ваш код или найти вам пример какой-то

Я отвечал на сообщение, где вы писали "вот предположим перехватили ваш запрос"

есть страница логин, юзер заполняет форму логина и пароля, и улетает запрос на сервер, бэк энд пишется на DJango + JWT, он исходя из данных генерирует токен и как response отправляет их (access и refresh), я раньше и то и другое хранил в localStorage, но выяснил то что хранить в localStorage это не безопасно

вот и прошу у вас совета, где лучше хранить рефреш токен

Оба точно нельзя там хранить

тогда посоветуйте пж, где и как лучше?

httpOnly cookie