Как сервер должен принимать токены авторизации в случае их установки им же с флагом http only?
Разбираюсь в теме работы с токенами, не могуть понять, как должна работать авторизация по токенам. Если сервер нам присылает токены через Set-Cookie, мы не можем получить к ним доступ с помощью java script, но для дальнейших запросов нам нужно установить заголовок Authorization: `Bearer ${access_token}`. Вижу следующий вариант:
access_token сервер нам присылает в теле ответа, а не через Set-Cookie, мы его сохраняем, например в locale storage, и работает с ним. Что бы обновить токен мы отправляем его по адресу обновления токена в заголовке авторизации и сервер уже берет рефреш токен из кук(ранее он туда сохранил refresh_token с помощью Set-Cookie при авторизации), вовзращает нам новый access_token и мы снова его сохраняем в locale storage. Все ли верно или я чего то не понял? Огромное кол-во статей и видео на эту тему, но везде разные реализации.
Для правильного вопроса надо знать половину ответа
Ну так единственно правильной реализации и не существует.
Через куки можно так:
Сервер присылает две куки с токенами. Рабочий токен установлен для example.com/api, а токен обновления для example.com/api/refresh. Теперь при рабочих запросах к /api браузер автоматически будет добавлять в куки рабочий токен, а когда сервер потребует обновления, то запрос на /api/refresh пойдёт с двумя токенами.
Разбираюсь в теме работы с токенами, не могуть понять, как должна работать авторизация по токенам. Если сервер нам присылает токены через Set-Cookie, мы не можем получить к ним доступ с помощью java script, но для дальнейших запросов нам нужно установить заголовок Authorization: `Bearer ${access_token}`
Можно сделать так хранить токен в куки файлах и особенности куки заключается в том чтобы сервер получил куки файлы не нужно писать заголовки. Не знаю какой у тебя сервер стоит, вот в Node js Express куки файлы можно легко получить через req.cookies и при каждом запросе на сервер ты можешь сделать middleware проверка токена
