@xanf_ua https://www.youtube.com/watch?v=XG-xOHogPkYИ я снова зарылся в видео и углубился в предложенную реализацию (еще раз спасибо за труд!).
Мне кажется, в такой архитектуре есть фундаментальный недостаток в частности если этот подход используется внутри SPA/браузера.
А что если открыто несколько вкладок? Конкурентность запросов на обновление токена неизбежна и ошибки неизбежны. В случае если мы решим применять localStorage, да, в этом случае во всех вкладках обновится токен, но вероятность ошибки просто уменьшится и добавится костылей вроде после ошибки обновления токена - посмотреть в локалСтор, не обновился ли там токен (соседней вкладкой?!).
Ну а если использовать это для микросервисного подхода, тогда конкурентность никак не разрешить.
Буду рад комментариям))
(мы как раз говорили недавно о хранении рефреш токена в куках доменной зоны через CORS самого логин сервера, но конкурентность неизбежна если несколько/много вкладок).
В этом случае можно конечно просто при ошибке протухания рефреш токена (если одна вкладка отослала запрос, но еще в ожидании ответа на рефреш.. и вторая вкладка начала тот же запрос, когда первая закончит, вторая зафейлится с ошибкой просроченного рефреша - просто повторить запрос на получение нового токена).
Я просто изучаю всевозможные подходы для авторизации.. хотелось подискутировать ОК ли подобный подход.
Я пока что увидел некую комбинацию refresh/аля токена сессии и access tokena который выдается на короткое время по сессии и так мы можем отслеживать юзер агента, айпишник и предполагать кто и откуда пытается компроментировать токен и отзывать его (нейронку обучить детектить)
Ну и плюс такой подход сильно уменьшит нагрузку на логин сервер и на хранилище сессий так как тот же access token будет жить хотя бы по 15 минут.
