Подскажите, пожалуйста, по JWT аунтификации. Как лучше аунтифицировать пользователя при SSR? Если

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

Что имеется в виду под "валидировать по рефреш"?

Проверять jwt. Валидный или нет. Т.е. аунтифицировать другими словами.

Аутентификация и авторизация происходят по access токену. Если для этого используется рефреш, то это называется "сессия", и никакой нужды в jwt нет

При ssr мы ведь не можем получить access токен, который хранится в памяти, только есть refresh, который есть в куках.

а как тогда быть имея jwt аунтификацию и SSR и стороне сервера + api для получения данных?

Если при SSR не происходит ни одного запроса на бэк апи с jwt, то разве что можно посоветовать добавить какой-нибудь ping апи

Есть у меня страница профиля например. И есть jwt на клиенте, ревереш и аксесс токены. Также у меня есть ревереш в базе данных. Пользователь переходит на URL /profile/. Здесь я бы хотел сделать рендеринг на стороне сервера, в противовес тому, что можно было отобразить скелетон, дождаться запросов от апи, рендера у клиента и т.д. Как мне на сервере понять, что этот пользователь тот за кого себя выдает, чтобы достать для него нужные данные и отредерить их на сервере?

А как получается, что если есть access, то refresh не нужен? Вроде как используя refresh обновляется access же

Это изначально неправильный подход. SSR нужен только для SEO. Профиль пользователя Гуглу не нужен 😂

просто на сервере я ведь не могу получить access, правильно? Access хранится на клиенет в памяти приложения. И нужен для получения данных. Это короткоживущий токен. Как только он истечет, я по ревреш токену получу новую пару.

Рефреш нужен для обновления access. Вот когда access истекает, нужен refresh

ты што! SSR новая веха во вротенде! блезингли фаст!

проверить токен пользователя...

возможно вы правы, гуглу точно не нужен. Но возможно нужен пользователю. Как по мне, куда приятней сразу видеть весь интерфейс, чем целое пустое окно скелетона. Экран моргает из-за перерендеров, не понятно что происходит. UI или как это правильно UX, как по мне не очень хороший.

Зачем вам jwt?

куки

Какой токен? ВОт я и спрашиваю, аксесс я получить не могу. Могу только ревреш из кук достать.

зачем рефреш?

Почему не можете? Что мешает отправить токен на сервер вместе с запросом? Собственно, всегда же так и делается, и токен ровно для этого и нужен

Мне нужно аунтифицировать пользователя. Я бы сделал на сессиях, но говорят, что эта история имеет больше минусов, чем плюсов, по отношению к оwt аунтификации. Масштабировани, CSFR атаки. Плюс если тот же редис отъедит, то все пользователи останутся незалогиненными и т.д.

Потому что я могу проверить его подпись и вытащить оттуда user id

Наоборот, сессии проще и имеют меньше недостатков, чем jwt. С jwt не получится разлогинивать пользователей

ты пишешь " И есть jwt на клиенте, ревереш и аксесс токены.", акцесс-токен суёшь на бек, он тебе данные пользователя даёт в ответ, стейт в приложении меняешь isAuth = true; С таким стейтом можешь показывать ему "защищённый маршрут" aka "protected route".

так аксес для чего

Холиварная тема. Проще сделать блэклист в редиске туда заносить аксессы короткоживущие, например если вам критично время жизни 15 минут. И это все равно быстрее искать по разлогиненным акссессам, чем по полной базе всех сессий. Плюс больше в том, что даже если редис упадет, ну и бог с ними с этими акссессами, которых несколько штук. А вот если на сессиях делать - у вас все юзеры отвалятся.

стандартная же схема, по-моему

> Экран моргает из-за перерендеров, не понятно что происходит Почините фронт, а не насилуйте SSR

Это когда я обрщаюсь к апи, тут вопросов нет. А если я хочу на сервере отрендирить страничку для пользователя, например /profile/. Что мне нужно проверить, чтобы понять, что он это он и что делать с токенами?

Сессии можно в бд хранить, не обязательно в редисе. Если бд отвалилась - ну сорян, тут уже мало что можно сделать Но в любом случае, даже если использовать jwt, как только рефреш становится носителем информации, сразу можно смотреть на предмет того, что пошло не так А в вашем вопросе всё ещё хуже: подразумевается использование рефреш как аксесс

SSR приятнее, ты получаешь все и сразу. А без SSR ты получаешь пустые слоты, которые никакой смысловой нагрузки не несут.

У вас мало клиентов с мобильных устройств

Я потому и спрашиваю. Как тут можно поступить, потому что не знаю, как правильно.

Фейсбук и Твиттер не парятся из-за пустых слотов при медленном интернете

Мобильки это немного другая история. Посмотрите как отображаются карты в браузере и приложении. Например, циан. В браузере все логает аж жуть, а в приложении, просто приятно пользоваться.

Догадываетесь почему?

Здесь скорее вопрос вкуса или точнее бизнес задач. Меня больше волнует техническая реализация.

НА ум приходит только лишь очевидные вещи, что работают они по-разному.

Зависит от твоей реализации. Можешь хранить данные пользователя в стейте, или в куках, и подставлять для рендеринга эти данные. Роут /profile должен быть защищённым. Либо при переходе на него каждый раз проверять токен, делая запрос к апи, опять же смотря что он тебе возвращает.

На эту тему куча материала в интернете есть.