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

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

Не подскажите как правильно работать с jwt через graphql ?  У меня есть запрос на беке tokenAuth (скармливаешь ему логин и пароль, получаешь jwt, если такие имеются в базе данных). Я думал, что достаточно потом этот jwt добавлять к каждому запросу отдельным параметров (типа, хочу создать новый пост, вместе с title и body добавляют поле token), но оно так всё равно не хочет работать(400 bad request). Как это правильно в моём случае делать?

первое важно понимать что jwt дырявый чуть менее чем полнсотью, это не отменяет его распростроненость (в моем проекте он тоже есть, как бы я его не ругал). Не нужно добавлять его как параметр, смотрите спецификацию, добавляйте в хедер, далее прокидывыйте его через контекст чтобы любой резолвер знал авторизован ли челвоек и кто он, ну а дальше миделвартку или как то еще

почему jwt дырявый? дыра в асимметричном шифровании? xd
или не нравится, что нужен “сервис токенов”?)

Вставлю 5 копеек, в jwt нет шифрования, только хеширование

>смотрите спецификацию
Для graphql в целом?

>добавляйте в хедер
 Ок,это же в спецификации должно быть?

Самый распространенный вопрос - как отозвать токен

“или не нравится, что нужен “сервис токенов”?)”

Ну вообще да, шифрование можно добавить, но это опционально

И что гипотетически можно вместо jwt использовать?

чтобы не дырявое

Сессии

сессии + ip внутри

по факту тоже самое, если бы jwt + сервис проверки валидности токенов

Да

либо костыль: expire jwt токена ставить в один час и надеяться, что в середине этого часа отзывать токен не придется)

Для таких случаев используют refresh token,  но проще конечно хранить

А этот рефреш хранится
И тогда каждый раз при обращении надо смотреть на рефреш токен, лезть в бд
И тогда вообще пропадает смысл подписи