Логика запросов страниц авторизации

[Raadsert]

Здравствуйте.

Подскажите, как устроены страницы авторизации на уровне запросов? Когда пользователь авторизовался в условной админке, ему выдаётся токен, и его переадресовывает на страницу админки. При дальнейших попытка зайти на страницу авторизации так же происходит переадресация. Не могу понять, как сервер при стандартных GET запросах определяет авторизован ли пользователь? Сервер ведь не может получить токен при стандартной загрузке страницы, ведь там нет заголовка с токеном. Мне на ум приходит только вариант с отправкой на клиент кода fetch с GET запросом, уже который передаст токен и будет возможность проверить авторизацию пользователя и соответственно сделать переадресацию, но это звучит как бред.

[Nexus]

Не могу понять, как сервер при стандартных GET запросах определяет авторизован ли пользователь?

С помощью cookies.

[Raadsert]

С помощью cookies.

Куки могут отправлять токен в стандартных GET запросах? А зачем тогда все советуют использовать localstorage?

[Rise]

ведь там нет заголовка с токеном

Есть, заголовок Cookie, его браузер вставляет в запросы. Удали куки на любом сайте и авторизация слетит. Не замечал?

[Nexus]

Куки передаются в каждом нативном запросе, поэтому это самый удобный способ авторизации для сайтов, контент которых генерируется сервером и доставляется синхронными запросами.

Вы можете положить ваш токен в куку и проверять её при каждом запросе к закрытой части приложения.
LocalStorage используется, когда приложение само отправляет запросы к api приложения. В этом случае вы можете подставлять токен в заголовки каждого запроса перед его отправкой.

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