Когда-то использовал такую схему: refresh в httpOnly cookie, access только в памяти клиента, без localStorage.

Access живёт недолго и нужен для запросов с Authorization: Bearer. Refresh живёт дольше и опаснее при утечке, поэтому его обычно прячут от JS через httpOnly cookie.

После F5 access из памяти пропадает, и это нормально. Чтобы восстановить сессию, клиент может вызвать POST /auth/refresh. Браузер сам приложит cookie, сервер проверит refresh и вернёт новый access.

Но refresh после перезагрузки вызывался не всегда. Для этого был hint в localStorage. Обычный флаг, не токен. Он говорил клиенту: здесь уже логинились, можно попробовать восстановить сессию.

Если hint был, клиент делал refresh по cookie. Если hint не было, сразу считал пользователя гостем и даже не пытался обновить access. Так мы не слали refresh каждому анонимному посетителю после каждого F5.

Но была интересная особенность. Если вручную удалить hint из localStorage, а refresh cookie ещё жива, получалось странное состояние 👇

Сервер всё ещё считает пользователя авторизованным, а клиент после перезагрузки ведёт себя так, будто был выполнен logout, и отправляет на страницу входа.

Получается, что связь между hint и refresh была только на клиенте. Hint без валидной cookie ничего не даёт. Но и cookie без hint после перезагрузки клиент сам не использует.

По сути, настоящая сессия здесь это refresh cookie и её состояние на сервере. Hint был лишь оптимизацией, чтобы не дёргать refresh лишний раз.

🫆 Я не эксперт по auth-схемам, это просто кейс из прошлого опыта. Интересно, как вы решаете это у себя? Где храните access и refresh? Нужен ли вообще такой hint? Или проще всегда пробовать refresh при старте приложения? Что делаете, если localStorage очистили, а cookie ещё валидна?