⬆️Начало выше⬆️

access_token - это такой токен, который мы можем проверить, что он был подписан секретным ключом сервера (см. Асимметричное шифрование, я делал пост о том как оно работает). Вообще.. это ровно то, что делает JWT токен сам по себе, так что наш JWT и будет сам по себе являться уже Access_token'ом. Но просто знайте, что в мире Oauth вы можете и сами "скрафтить" всё то же самое, просто JWT это стандарт. Обычно, "живучесть" этого токена небольшая. Именно это свойство позволяет гарантировать, что даже если злоумышленник украдёт его - "доступа к апи" у него останется на n минут, если он вообще сможет вовремя им воспользоваться. +у него не будет ни пароля ни логина. Идеально! Вне мира JWT, это вполне может быть "Bearer {access_token}", что часто и бывает.

refresh_token - а этот токен нужен для того чтобы когда истёк access_token, мы сбегали на сервер и взяли новую пару "access+refresh". Срок протухания этого токена уже может быть и день и десять и месяц - зависит от бизнеса.

В чём соль-то?
Трюк тут в том, что получив при логине эту пару токенов вы

а) Сохраняете refresh_token на сервере и привязываете к пользователю.
б) Зашиваете refresh_token в ПАМЯТЬ (если у вас SPA приложение), или в Local Storage (он не передаётся на сервер с каждым запросом) или как вариант - ставите куку с ограничением, что слаться она может только по урлу запроса новой пары токенов. Суть в том, что этот токен НЕ БЕГАЕТ в разные API, он ждёт своего часа, а именно - когда протухнет access_token.
в) Все запросы из браузера теперь бегают с access_token (в нашем случае с JWT). В JWT "зашиваем" expiration_date. Как только мы понимаем, что JWT "протух", сразу же кидаем 403 (Forbidden) и клиент бежит за новой парой токенов. А этот уже становится невалидным.
г) Как только клиент (браузер) получает 403, он сразу же копается у себя в памяти/куке, достаёт сохранённый refresh_token, бежит на какой-нибудь /authenticate_token, где сервер валидирует JWT токен, достаёт оттуд юзера, смотрит в базу (или кэш), сопоставляет с присланным refresh_token (а так же проверяем не стух ли refresh) и если всё совпадает - прекрасно! Выдаём клиенту обновлённый. Если рефреш стух или мы отозвали все токены из базы (просто удалив), то кидаем клиенту допустим ошибку 401 (Not Authorized) и клиент уже понимает - всё, тут уже без странички логина не обойтись.

Фух. Объяснил на пальцах, так объяснил. Ну... как есть, ребят 🙃

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

Спасибо за внимание и лайк не забудь 😁