Гайс привет. Имеется сервис, который выдаёт jwt и сам же

по нему аутентифицирует юзера.

Подскажите, в какую сторону копать если я не хочу чтобы пользователь перелогинивался каждые n минут за новым токеном? Возможно ли сделать это без хранения сессий?
Возможно ли сделать это без refresh-токена используя только один jwt и логику на фронте?

нет, ничего хорошего из этого не придумаешь

Тогда какие самые безболезненные варианты есть?

Ты либо хранишь информацию о времени жизни токена в самом токене и опираешься на нее. Либо хранишь ее в неком сервисе/базе и тем самым переизобретаешь обыкновенные сессии, теряя преимущества жвт.

Информация о жизни хранится в jwt. Вопрос о выпуске нового токена\

Дополню - насколько норм держать refresh-токен в сессионной куке?

если у тебя уже есть сессия нахуя тебе рефреш? а если вопрос "норм ли пихать рефреш в куки?" то да, норм

Access просрочился - фронт сходил и забрал новый без перелогина

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

Стикер

Сори за затупы) Кука и будет сессией же

в t.me/fastapi_ru куча раз обсасывали этот рефреш, советую полистать(в поиске просто рефреш вбить вроде достаточно)

Хорош, спс

Смысл refresh-токена в том, что бы не пользовать его на каждый запрос. Иначе увеличивается риск что его уведут. А ты собрался его засунуть в куку, что бы он вообще на любые запросы к домену (даже если это не API) улетал на сервер.

Алсо он же https-protected

ну нормальная тема ж, в хттп онли куку его

букву потерял)

какую

c

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies

И нахуа он тогда вообще нужен? То же самое что id сессии. JS его даже прочитать не сможет, что бы самостоятельно вызвать API для обновления аксес-токена

ой

жс получает 403 и идет рефрешить

Храни его в Local Storage бразуера, не надо его в куки пихать

не надо в local storage ниче класть

Тогда зачем умные люди придумали эту всю сложность с двумя токенами? Юзали бы один, раз он и так защищён https-ом.

Не путай refresh token и сессию

Чобля? Смысл refresh токена перевыпускать access token. Все.

Ебушки-воробушки. Вы там совсем ебанулись на отличненько что ли?

Потому что разные токены предназначены для разных сервисов.

refresh token отправляется на Authorization Server, а access token отправляется на Resource Server.

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

так проблема одна - взяли рефреш для хз чего и поэтому гоняем хз как

1. Потому что система хуево построена и взяли от балды. 2. Потому что BFF бекенд стейтлесс и это компромисс.

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

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

А зачем их хранить на бекенде? Рефреш ведь должен хранить клиент, который использует аксес.

Ну так OAuth клиентом и выступает бекенд, для другого сервиса

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

В общем нужно смотреть на конкретный ценарий, потому что от этого схема аутентификации очень сильно зависит.