Допустим, у пользователя закончился срок действия токена. Окей, он стучится на сервер auth со своим просроченным token’он, auth смотрит, что есть старый токен, окей, старый меняем на новый.

Не-не-не, просроченынй значит просроченный, на токое надо пересылать на новую авторизацию. Клиент должен периодически приходить с действующим токеном на обновление.

Токен перехватили

Поэтому у токена короткий срок годности. Его нельзя инвалидировать.

Допустим, у пользователя закончился срок действия токена.

Он делает запрос. Его отшивают с ошибкой – просрочено. Он берёт refresh_token и обновляет свой access_token. Если и там отшивают с «просрочено», то это sign out.

Токен перехватили.

Да никак. Токен будет жив и дейстовать до конца своего времени действия. Если речь о серьёзных операциях, то всё упирается только во время жизни токена. Например, для банков это минут 20 максимум, если не меньше.

P.S. иначе JWT просто не имеет смысла. Т.к. JWT – это права выданные на определённое время без возможности отзыва. Если есть отзыв, то это доступ к БД, а значит и огород городить смысла нет. Так думаю.

А как отзывать refresh_token-ы, если они не хранятся на сервере?

А как отзывать refresh_token-ы, если они не хранятся на сервере?

Refresh_token должен быть одноразовым и без сервера этого не получить. По идее, если злоумышленник утащит access_token, то он сможет беспределить время жизни этого токена. Если он утащит refresh_token, то в этот момент пользователь обломается с обновлением своего refresh_token-а (т.к его уже укали и использовали) и пройдёт процедуру Sign In, что отзовёт краденый refresh. Если пользователь в оффлайне надолго, то злоумышленник может беспределить очень долго. Т.к. обновлять пары токенов он может бесконечно.

Т.е. злоумышленник получает доступ на время жизни access_token в любом случае. Но при этом все клиенты долбят сервер и БД через каждый период жизни acess_token (в случай активности этих пользователей, иначе меньше безо всякого sign out-а).

Иначе в refresh_token-е особого смысла нет. Т.к. угнать его так же сложно/просто как и access_token – отличий нет.

По сути refresh_token – способ дать полный доступ, но не давать его надолго. Типа того.

Если refresh_token не храниться в БД, то в течении его времени жизни любой может выписать себе сколько хочет пар access/refresh-токенов. Что само по себе слегка адово.

Так же это касается и бана пользователей. Если забанить пользователя. То время жизни access_token он всё ещё будет устраивать срач. А потом всё.

стучится на сервер auth со своим просроченным token’он, auth смотрит, что есть старый токен, окей, старый меняем на новый

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

Общее положение: auth имеет riv key, с помощью которого выдает refresh_token и access token. Он же занимается перевыдачей refresh_token и access token. Profile занимается регистрацией пользователей по username(phone), user_password.

Реализацию можно разделить на два подхода:

1. Auth генерирует refresh_token и access_token . Profile расшифровывает access_token локально без обращения к auth. И этого хотелось бы добиться в итоге(и возможно ли это?)

2. Auth генерирует refresh_token и access_token . Profile расшифровывает access_token, внутри которого есть некий идентификатор, который является индикатором того, что access_token выдан валидным на текущий момент refresh_token. При расшифровке access_token profile стучится в auth, где сохранен этот идентификатор, смотрит, если идентификатор валидный - значит этот access_token валидный

По первому пункту всё ясно(если учесть, что profile не стучится в auth за валидацией access_token). И я не думаю, что можно как-то технически реализовать валидацию access_token

По второму пункту - всё сложней. Мне и сейчас в полном объеме не ясно как происходит перевыдача refresh_token(потому что его могли украсть). Вообще, если взять и начать отвечать на этот вопрос не текстом, а формированием полей внутри токенов, то сразу появляется много вводных, которые нужно обрабатывать

PS:Я лично считаю, что невозможно перевыпускать refresh_token без какой-то идентификации клиента(т.е пароля или фингерпринта отпечатка пальца(или что там используется))

PPSS: на текущий момент времени нет готового решения для того, чтобы решить вопрос централизованной безопасной token авторизации в djangorest

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

Токены делятся на реально короткоживущие JWT и сравнительно долгоживущие refresh-токены. refresh можно отозвать (тупо в блеклист записать, например, или поменять ключ шифрования, что обычно инвалидирует все токены), обычный – никак, вообще. В этом суть JWT.

Кстати, поэтому использовать JWT для сессий — плохая идея. Юзкейс JWT — когда все токены одноразовые, в этом случае инвалидировать по определению не нужно.

По-моему вы путаете тёплое с мягким, JWT (https://tools.ietf.org/html/rfc7519) не подразумевает аутентификацию и/или авторизацию, это грубо говоря всего лишь способ получить строку (токен), внутри которого можно засунуть данные и механизм, при котором исключается подмена данных. Другими словами, JWT можно использовать вне авторизации или аутентификации, и авторизация и аутентификация может работать без JWT. Ав

Refresh_token должен быть одноразовым и без сервера этого не получить.

Не обязательно, например в OAuth2 (https://tools.ietf.org/html/rfc6749) refresh_token может быть долгоживущим, и в ответ на обновление токена приходит тот же самый refresh_token и новый access_token, предыдущий access_token инвалидируется. Более того, access_token можно обновить до того, как он протухнет, и тогда он будет невалидным, даже если ещё не протух.

По идее, если злоумышленник утащит access_token, то он сможет беспределить время жизни этого токена.

До тех пор пока токен не будет отозван.

Т.к. обновлять пары токенов он может бесконечно.

Если refresh_token долгоживущий, то бесконечно не получится, обновлять можно будет либо пока refresh_token не протух, либо пока не отозван. Чтобы получить новый refresh_token, надо заново пройти аутентификацию.

То время жизни access_token он всё ещё будет устраивать срач.

В той же OAuth2 можно отозвать токен, тогда срач не получится устроить.

Токен перехватили.

Тогда токен отзывается.

Да никак. Токен будет жив и дейстовать до конца своего времени действия. Если речь о серьёзных операциях, то всё упирается только во время жизни токена. Например, для банков это минут 20 максимум, если не меньше.

Это дырка в безопасности, никто в здравом уме на такое не пойдёт.

Т.к. JWT – это права выданные на определённое время без возможности отзыва. Если есть отзыв, то это доступ к БД, а значит и огород городить смысла нет. Так думаю.

Нет, JWT - это не права, это всего лишь способ формирования строки с некими данными и механизм, который позволяет исключить изменения данных. Почитайте, пожалуйста, стандарт https://tools.ietf.org/html/rfc7519. Также вы сможете заметить, что про хранение JWT на сервере в стандарте вообще ни слова, т. е. на самом деле хранить JWT можно.

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

обычный – никак, вообще. В этом суть JWT.

В https://tools.ietf.org/html/rfc7519 вообще ни слова про отзыв. А всё потому что JWT - это не про аутентификацию и авторизацию. Поэтому его вполне можно отозвать. Если токен нельзя отозвать, то это дырка в безопасности.

Если токен «одноразовый», то как проверить, что вызов с таким токеном уже был?

Другими словами, JWT можно использовать вне авторизации или аутентификации, и авторизация и аутентификация может работать без JWT.

Да неужели? А зубной щёткой можно неплохо так подметать асфальт. Главное прикрутить к ней лом вместо ручки.

До тех пор пока токен не будет отозван.

Токен нельзя отозвать. Отзыв токена – трахаться с БД. Нет смысла с JWT. Круг замыкается.

Если refresh_token долгоживущий, то бесконечно не получится, обновлять можно будет либо пока refresh_token не протух, либо пока не отозван. Чтобы получить новый refresh_token, надо заново пройти аутентификацию.

Обновление refresh_token выписывает новый – свежий.

В той же OAuth2 можно отозвать токен, тогда срач не получится устроить.

Если есть механизм отзыва, есть доступ к БД. Есть доступ к БД – простой session key всё решает и никакой JWT не нужен. Дополнительно проверять подписи на каждый чих просто так типа?

Тогда токен отзывается.

Не, не отзывается.

Это дырка в безопасности, никто в здравом уме на такое не пойдёт.

Не, не дырка. А the way it meant to be used.

Также вы сможете заметить, что про хранение JWT на сервере в стандарте вообще ни слова, т. е. на самом деле хранить JWT можно.

От чего он теряет смысл.

Да неужели? А зубной щёткой можно неплохо так подметать асфальт. Главное прикрутить к ней лом вместо ручки.

То есть аргументов нет? Ладно.

Токен нельзя отозвать. Отзыв токена – трахаться с БД. Нет смысла с JWT. Круг замыкается.

Токен отозваться можно. Это раз. JWT - это не про авторизацию или аутентификацию, так что мимо. Два. Пожалуйста, почитай стандарт https://tools.ietf.org/html/rfc7519

Если токен отозвать нельзя, то это дырка в безопасности.

Дополнительно проверять подписи на каждый чих просто так типа?

Вот если почитать стандарт, то станет понятно, что там не только проверка подписи. Собственно говоря, JWT не ради проверки подписи сделали.

Не, не отзывается.

А я могу отозвать токен. Что мне мешает это сделать? RFC 7519? Или давай так, в каком стандарте, RFC указано, что нельзя отозвать токен?

Не, не дырка. А the way it meant to be used.

Банк клиент, у пользователя утёк токен. В нормальной системе токен отзывается и злоумышленник уже ничего не сможет сделать. А если с токеном уже ничего сделать нельзя, то это дырка в безопасности.

От чего он теряет смысл.

Какой смысл? Где про этот смысл можно почитать?

То есть аргументов нет? Ладно.

Я тебе привёл аргументы, просто ты так и не смог их увидеть. Машешь спекой, а понять сложить одно к другому не смог. Ну и какой смысл мне далее распылятся на аргументы? Какой?

Токен отозваться можно. Это раз. JWT - это не про авторизацию или аутентификацию, так что мимо. Два. Пожалуйста, почитай стандарт https://tools.ietf.org/html/rfc7519

Я по-моему ясно дал понять, что смысла в отзываемом aceess_token нет никакого. А то, что ты можешь – ну можешь, только профит в чём пояснить сможешь? Или тебе дотаочно стильности и модности JWT как технологии? Ну поздравляю – это называется быть оленёнком.

Если токен отозвать нельзя, то это дырка в безопасности.

Нет никакой дырки. Утечка токена – ситуация эквивалентная потере компа с разлогиненым аккаунтом. Т.е. достаточно только инвалидировать refresh_token.

Вот если почитать стандарт, то станет понятно, что там не только проверка подписи. Собственно говоря, JWT не ради проверки подписи сделали.

«Поциент так и не смог пояснить». Так и запишем.

А я могу отозвать токен. Что мне мешает это сделать? RFC 7519? Или давай так, в каком стандарте, RFC указано, что нельзя отозвать токен?

Здравый смысл. Т.е. тебе в принципе ничего не мешает. А вообще так не делают.

Банк клиент, у пользователя утёк токен. В нормальной системе токен отзывается и злоумышленник уже ничего не сможет сделать. А если с токеном уже ничего сделать нельзя, то это дырка в безопасности.

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

Я тебе привёл аргументы, просто ты так и не смог их увидеть.

«Поциент так и не смог пояснить». Так и запишем.

Ещё раз, JWT может применяться не только для аутентификации и авторизации. Но может ещё применять для обмена данными. Например, подтверждение email-а, когда пользователю отправляется на email ссылка с JWT-токеном, в котором записан UUID пользователя и подтверждаемый email. И на сервере только проверяем, что токен не протух и валидный. Если так, то email подтверждён, если нет, то до свидания. Авторизация? Нет. Аутентификация? Нет. Поэтому аргументы про зубную щётку вообще мимо, как и аргумент, что JWT применяется исключительно для авторизации.

Я по-моему ясно дал понять, что смысла в отзываемом aceess_token нет никакого.

А я по-моему тоже ясно дал понять, что смысл в отзыве access_token-е есть.

А то, что ты можешь – ну можешь, только профит в чём пояснить сможешь?

Так уже ниже пояснил. Во-первых, если токен утёк. Во-вторых, если пользователь меняет или сбрасывает пароль, то все существующие токены, которые выданы по старому паролю, надо отзывать. В-третьих, если пользователь решил включить 2fa, то также все текущие активные токены надо отзывать, чтобы пользователь сначала зашёл по 2fa, потом получил новую пару (access_token, refresh_token) для доступа к ресурсам. Или для вас ситуация, когда пользователь получил получил (access_token, refresh_token), потом сменил пароль, но продолжает ходить со старым access_token-ом и обновлять его через refresh_token - адекватная?

«Поциент так и не смог пояснить». Так и запишем.

Хорошо, видимо, пройти по ссылке https://jwt.io/introduction/ и прочитать первое предложение: «JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.» слишком сложно. И даже зайти на сайт https://jwt.io и прочитать в разделе https://jwt.io/introduction/:

Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn’t been tampered with.

совсем сложно.

А вообще так не делают.

Кто тебе эту чушь сказал? Адекватные люди сначала думают перед тем как что-то делать и взвешивают все «за» и «против».

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

Никто не говорит, что происходит 0 мин 0 сек. Но даже если в момент обнаружения внедрения смогли инвалидировать токен, то это может как минимум снизить ущерб. По аналогии, пользователь обратился в банк, чтобы заблокировали карту, а через 5 минут с заблокированной карты уводят деньги: «Ну понимаете, там JWT, мы не можем отозвать токен, поэтому злоумышленник может делать что-угодно с картой».

Но может ещё применять для обмена данными.

Как HMAC, что вряд ли нужно вообще кому-то в сфере «бекенд и мобильная аплека». А если и есть, то вопрос применимости не стоит.

JWT применяется исключительно для авторизации

Это ты выдумал и решил оспорить. Поздравляю. Зачем только мне при этом пишешь? Спорь сам с собой, мне не интересно.

А я по-моему тоже ясно дал понять, что смысл в отзыве access_token-е есть.

Не ты просто машешь спекой, забывая о реальном мире.

Так уже ниже пояснил.

Нет не пояснил, а продолжаешь утверждать, что это нужно.

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

Отзываешь refresh_token и всё.

И даже зайти на сайт https://jwt.io

Ну так я говорю о реальном мире. С помощью JWT можно много чего нагородить. Только профита от этого ноль.

совсем сложно.

Аналогично.

Кто тебе эту чушь сказал? Адекватные люди сначала думают перед тем как что-то делать и взвешивают все «за» и «против».

Да и после взвешивание приходят к выводу, что использовать JWT вместо session key как минимум странно.

Никто не говорит, что происходит 0 мин 0 сек. Но даже если в момент обнаружения внедрения смогли инвалидировать токен, то это может как минимум снизить ущерб. По аналогии, пользователь обратился в банк, чтобы заблокировали карту, а через 5 минут с заблокированной карты уводят деньги: «Ну понимаете, там JWT, мы не можем отозвать токен, поэтому злоумышленник может делать что-угодно с картой».

Зачем JWT если каждый раз при этом смотреть в БД ты так пояснить/понять не смог.

Как HMAC, что вряд ли нужно вообще кому-то в сфере «бекенд и мобильная аплека». А если и есть, то вопрос применимости не стоит.

Не только как HMAC. И речь идёт не только о сфере «бекенд и мобильная аплека».

Это ты выдумал и решил оспорить. Поздравляю. Зачем только мне при этом пишешь? Спорь сам с собой, мне не интересно.

А вот здесь Принципы перевыдачи JWT токенов (комментарий) ты без аргументов на фразу, что JWT применяется не только для авторизации, пишешь

Да неужели? А зубной щёткой можно неплохо так подметать асфальт. Главное прикрутить к ней лом вместо ручки.

Ты уж определись, применяется ли JWT только для авторизации или не только.

Не ты просто машешь спекой, забывая о реальном мире.

Не забываю, просто есть люди, которые рассуждают о вещам, не имея представления о них.

Нет не пояснил, а продолжаешь утверждать, что это нужно.

Пояснил.

Отзываешь refresh_token и всё.

Но подожди, как ты отзовёшь refresh_token, который представляет из себя тоже JWT-токен? Неужели на сервере будешь хранить?

Ну так я говорю о реальном мире. С помощью JWT можно много чего нагородить. Только профита от этого ноль.

Если ты этого не знаешь или не понимаешь, то это не значит, что профита от этого ноль.

Зачем JWT если каждый раз при этом смотреть в БД ты так пояснить/понять не смог.

Не всегда есть смысл хранить все данные из токена в СУБД. Или например, если есть интеграция со сторонней системой, то нужно туда передать какие-либо данные (тот же UUID пользователя). Или в какой-нибудь платёжной системе, надо сгенерировать токен, который может пройти через 3-4 посредников до того, как доберётся до пользователя, но заказчик смог бы из токена достать ID ордера, при этом быть уверенным, что подмены не было.

И речь идёт не только о сфере «бекенд и мобильная аплека».

Да неужели?

А вот здесь Принципы перевыдачи JWT токенов (комментарий) ты без аргументов на фразу, что JWT применяется не только для авторизации, пишешь

Он используется только как HMAC вообще везде. Просто c JWT удобней работать. И, т.к. там есть подпись строга, то занчит и user_id и прочее можно там смело хранить и на основании этого уже авторизовывать.

Вот только смысла в этом нет, если ты собрался каждый раз дёргать БД. Ни-ка-ко-го во-об-ще. Это именно то, чем отличается реальный мир от спецификации. В реальном мире, если дёргаешь БД на каждый чих – горадо проще пулять просто session key и двигаться от него. Т.к. JWT в довесок усложняет систему и требует подписи – криптографии там всякие.

То что ты можешь в теории напридумывать меня мало интересует. Потому что это менее удобно. И менее эффективно. Разве это не так?

Если ты этого не знаешь или не понимаешь, то это не значит, что профита от этого ноль.

А если это не только я?

Не всегда есть смысл хранить все данные из токена в СУБД. Или например, если есть интеграция со сторонней системой, то нужно туда передать какие-либо данные (тот же UUID пользователя). Или в какой-нибудь платёжной системе, надо сгенерировать токен, который может пройти через 3-4 посредников до того, как доберётся до пользователя, но заказчик смог бы из токена достать ID ордера, при этом быть уверенным, что подмены не было.

В этом случае один и тот же токен используется и для авторизации и для подписи. Если одельно – то это просто подпись, типа HMAC. И что? На авторизацию это никак не влияет. Если отдельно – то это отдельная тема. Т.к. здесь он используется только как типа HMAC. Но при чём тут тогда отзыв и всё такое. Те 3-4 посредника никак не узнают про всё это, про бан и понижение в правах. Всё что они могут знать – достоверны ли данные в токене.

P.S. может быть выгодно использовать JWT вместо session key – если но используется и для авторизации и для чего-то ещё – я согласен.

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

сразу видно кто работал с oauth и jwt, а кто рядом стоял.

1. Нет, для этого есть refresh_token.

2. Автоматически - никак. Человек где-то кликает «разлогинить все устройства» и когда в следующий раз клиент приходит с устаревшим ревреш_токеном то не получает аццес_токен.

Но подожди, как ты отзовёшь refresh_token, который представляет из себя тоже JWT-токен? Неужели на сервере будешь хранить?

А ты знаешь какой-то друго способ обеспечения одноразовости? Я весь внимание. Неужели его всё-таки изобрели, а я не в курсе. Скорее же сообщи.

Для детишек, кто не работал с HMAC. От того они так фонтанируют. Между прочим JSON – один из худших форматов для хранения ограниченных по размеру данных. Но только детишки не смогут распарсить colon-separated values, а JSON в твоём любимом JS – родной формат. Вот и всё.

Да ты совсем поехавший. Тебе конкретно лечиться надо. Сколько лет существуют Authorization-заголовки со всякой подписанной лабудой. Для и не только, авторизации. А ты только с приходом JWT проснулся и начал вскукорекивать. Да ещё как. Иди проспись, потом подходи. Я тебя разделаю под орех, за каждый твой дешёвый вскукорек.

Начать лучше отсюда:

(TL;DR: в 95% случаев тебе тупо хватит механизма сессий твоего веб-фреймворка, вот их и используй)

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Конкретно JWT - проще не использовать, чем отзывать:

https://stackoverflow.com/questions/31919067/how-can-i-revoke-a-jwt-token

В OAuth2 в принципе описан механизм отзыва: https://tools.ietf.org/html/rfc7009

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

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

Токен перехватили.

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

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

Токен нельзя отозвать. Отзыв токена – трахаться с БД. Нет смысла с JWT. Круг замыкается.

Ого еще и с бд надо работать, ну это явно слишком сложно для программиста. В чем реально проблема то? Пока вижу - только в твоей лени.

В том, что многие прикручивают JWT только ради stateless-микросервисов. База добавляет немного latency и её нужно отдельно масштабировать. В юзкейсе топикстартера немного не то, но если всё это ещё и в вебе — в случае с базой часто юзают старые добрые куки с ID сессии.

Да, но это не отменяет возможности отзыва. Тут ведь нужна не полноценная база - какого-нибудь мемкеша достаточно, вобщем все сильно зависит от конкретного кейса.

Там товарищ утверждал, что JWT вообще нельзя ни в коем случае хранить в субд на бэке, иначе теряется смысл JWT.

У тебя аргументы закончились, поэтому ты съехал на личные обвинения? Хорошо, твой слив засчитан.

Да неужели?

Представь себе.

Вот только смысла в этом нет, если ты собрался каждый раз дёргать БД. Ни-ка-ко-го во-об-ще.

И как ты собрался отзывать refresh_token, который JWT-токен, и который у тебя не хранится на бэке. А если нажать logout в приложении до того как истечёт access_token, то как сделать, чтобы по этому токену нельзя было получить доступ к ресурсам?

В моём примере вообще нет авторизации, проспись. И зачем это используется, уже написал (и не один раз). И даже дал ссылки, где об этом написано.

Он не в теме, нет смысла с ним спорить, пусть сначала доку почитает.

Просто не надо использовать JWT, лол. Обычные классические сессии в БД ничем не хуже и всем лучше.

И как ты собрался отзывать refresh_token, который JWT-токен, и который у тебя не хранится на бэке. А если нажать logout в приложении до того как истечёт access_token, то как сделать, чтобы по этому токену нельзя было получить доступ к ресурсам?

Читать научись.

В моём примере вообще нет авторизации.

Ровно как и здравого смысла во всех твоих репликах.

По поводу пункта 1:

1. Юзер успешно логинится и получает 2 токена: access и refresh

access - jwt, короткоживущий (например, 1 минута), никуда не записывается

refresh - uuid, долгоживущий (время его жизни = время жизни сессии при неактивности юзера), записывается в таблицу в базу вместе со временем его истечения

access может хранить в себе доп. информацию (права доступа, id юзера и т.п.)

2. access-токен во фронте пишется в переменную, а refresh выставляется в виде секьюрной httponly куки.

3. При всех запросах к серверу в http-заголовке передаётся access - и там он валидируется без обращения к СУБД (поэтому он jwt)

4. Если http-запрос к серверу вернул 401 при наличии access токена, то это значит, что либо токен невалидный, либо истек (что по своей сути одно и то же). В таком случае фронтенд должен сделать запрос к урлу для рефреша двух токенов, передав туда refresh-токен (куку)

5. На сервере в базе ищется этот refresh-токен, проверяется его время жизни - и формируется новая пара токенов. Предыдущий refresh-токен удаляется из таблицы СУБД.

6. Если запрос рефреша токенов вернул тоже 401, то это значит, что юзера надо разлогинивать во фронтенде.

Подробней читай вот тут

По поводу пункта 2:

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

refresh перехватили? Ну ок, реальный владалец учетки, авторизуясь, сделает refresh невалидным, потому что при получении пары токенов украденный refresh будет выпилен из таблицы СУБД. Если же реальный владелец учётки не заходит вообще, то, да, злоумышленник сможет бесконечно продлевать свою сессию. Но как ты сможешь refresh, кстати, перехватить?

Никак вы, бл-дь, не научитесь (c)

https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/