Нахера вам эти access_token и refresh_token и как это всё работает?
Залетел мне тут от друга вопрос - зачем нужен refresh_token в JWT? И что вообще такое это ваше ДЖЭВЭТЭ, блэт???
О JWT чуть ниже, а ответ на первый вопрос казалось бы лежит на поверхности - "Ну эээээ, чтобы забрать новый access_token". Ответ верный, да только ясности не добавляет зачем хромому костыль, ведь можно просто ... скажем хранить access_token с каким-то там expiration и проверять каждый раз. Да?
Нет.
Я пятнадцать лет гребу, а пришлось три часа убить чтобы раскопать этот вопрос. Стыд и срам, конечно, но что поделать. Реально очень смешно, что какую статью не начни читать - там 100500 мнений зачем КОНЦЕПТУАЛЬНО нужен refresh_token. Разбираемся 😊
И так, JWT (Читается кстати не ДЖИВИТИ и не ДЖЕЙ ДАБЛВИ ТИ, а ДЖОТ!) - Json Web Tokens стандарт бла бла бла. В википедии сходите почитайте!
Если короче - это такой хитрый джсончик, который состоит из хедера, body и подписи. И нужен для того чтобы гонять его с сервера в браузер и обратно. Для аутентификации запроса пользователя.
Как это работает. На пальцах.
Смотрите, вот логинится пользователь на сайте. Вводит логин и пароль. Мы бежим в базу, проверяем что да, такой пользователь и правда валяется, а ... что дальше? Ведь чтобы получить доступ к личному кабинету и API личного кабинета на сайте ... нужны эти логин и пароль. Мы же не можем просто сделать редирект и дальше не проверять запросы, ведь нам важно понять в КАЖДОМ запросе - а этот ли пользователь его шлёт? Или другой? А какой конкретно?
Поэтому. Мы можем сохранить логин и пароль пользователя и передавать его при каждом запросе к API. Звучит хорошо, не правда ли? Но нет. Это чревато тем, что очень не хотелось бы гонять такие важные данные как пароль и логин каждые пару секунд пользования сайтом. Так не носят. И браузер ваш взломать могут и трафик перехватить и чё только не могут.
Поэтому2. Мы на сервере генерируем JWT токен, засовываем в него айди пользователя и ... подписываем получившийся JSON'чик секретным ключом, предварительно сгенерировав его и положив в какой-нибудь конфиг на сервере. В итоге, наш JWT состоит из Header'а с деталями алгоритма, из "тела" с айдишкой пользователя и каким-то хэшем на конце (подпись). Вот тут можно поиграться и посмотреть на структуру : https://jwt.io/
Важно понимать, что сам токен может быть прочитан КЕМ УГОДНО, т.к. все эти данные - открытые, не шифрованные (именно поэтому в JWT никогда нельзя засовывать sensitive data без предварительной шифровки). Но я же могу подменить тот самый ID и тем самым подменить пользователя - скажете вы. Но нет. Не можете. Для этого вы поменяете Body, а вот ХЭШ, который находится в конце - не сможете, т.к. не знаете секретного ключа сервера. В отличии от самого сервера, который может получить такой токен и проверить, что Body подписан правильно (применив свой секретный ключ и сравнив с "хвостом" токена).
Круто, разобрались немного. Так вот, вы логинитесь. И отдаёте в браузер такой вот JWT токен, который сможете чуть позже проверить. Круто? Круто. Теперь у вас между браузером и сервером постоянно бегает cookie с этим токеном, вы каждый раз проверяете её и всё отлично. Но ... если эту куку перехватит злоумышленник - он ведь сможет воспользоваться ей чтобы выдать себя за пользователя, верно? Верно. Злоумышленник не узнает логин и пароль, но сможет "прикинуться вами". Чё делать?
На сцену выходят access и refresh токены!
Смысл их в том, что при помощи них мы сможем понять - а не пора ли нам снова закинуть пользователя на логин страничку?А так же не позволить злоумышленнику выдать себя за нас. Но зачем оба?
(Вообще, я тут конечно немного помиксал Oauth и JWT, т.к. первый как раз и использует токены, а второй самодостаточный, однако вместе они друг друга дополняют... не забивайте голову).
⬇️Продолжение чуть ниже⬇️