Как делпоится бек и фронт - вообще не важно. Страница всегда загружается в браузере, запрос всегда уходит на апп сервер. Так что хоть ты генерируешь страницы на сервере с помощью Tymeleaf/JSP/Velocity/etc, хоть с помощью JS - ты можешь продолжать в любом случае использовать JS и слать AJAX POST запрос. Это не взаимоисключающие вещи.

Альтернатива такому подходу (когда запросы шлет JS): HTML формы . Сам браузер будет формировать список параметров исходя из данных в форме и отсылать такой запрос на BE. Со стороны BE мы проверяем креды и устанавливаем SESSIONID в куках response header'a (это как раз делает Spring Security). Ну и делаем редирект на какую-то страницу после удачного логина.

авторСервер проверял всё, создавал секюрити контекст, выдавал юзеру токенКакой токен? Счас речь не про OAuth2 случайно? Или все таки может SESSIONID а не токен? И что за Auth, может Authorization header ?

Да, давай сначала в терминологии и подходах разберемся. При логине нам нужно создавать HTTP Session (речь даже не про спринг). По сути все сводится к:
1. Если имя/пароль верные, то сервер обратно браузеру в Response Headers отдает куки. Назовем ее SESSIONCOOKIE.
2. Т.к. кука - это такой хедер, который с каждым запросом шлется на сервер, то этот SESSIONCOOKIE теперь и будет приходить со всеми последующими на наш сервер.
3. Когда мы на сервере генерили эту SESSIONCOOKIE, то мы ассоциировали ее с каким-то состоянием (как правило за нас это делает Tomcat, мы просто дергаем метод getSession()). Т.е. под капотом у нас есть мапа: Map<String, SessionContent> - в этой мапе ключом является SESSIONCOOKIE, а значением - ну что захотим. Обычно там хранится как минимум имя пользователя который эту сессию создал.
3.1 И т.к. с клиента нам пришел SESSIONCOOKIE, то мы можем проверить есть ли такой ключ в мапе, и если есть - вытащить имя пользователя.

Да, название куки не принципиально - это может быть SESSIONID или Auth. Но все-таки мы привыкли называть его SESSIONID, другое название может сбить с толку. Но важно что он не является отдельным хедером, он хранится внутри хедера Cookies. Именно его браузер сохраняет и сам будет добавлять в каждый запрос. И именно из него сервер будет его потом доставать.

Если же ты создашь просто хедер SESSIONID, то JS может его и получит, однако после рефреша страницы все состояние JS'a сотрется и прийдется логиниться заново. А вот Cookies браузер сохранит в своем хранилище автоматически. И после рефреша страницы он останется.

Так же есть понятие Authorization header'a - это штука совсем другая, это альтернативный способ аутентификации. Это еще один спец хедер. В зависимости от типа авторизации там могут быть разные данные, однако когда речь идет про браузер, то как правило используют тип Basic Auth. В таком случае туда складывают username & password пользователя. Для этого серверу нужно вернуть в запросе информацию о том он хочет авторизовывать именно с помощью Basic Auth. И тогда браузе покажет свое нативное окошко (не HTML & JS), куда пользователь введет имя и пароль. И они при каждом запросе будут слаться на сервер. Этот хедер браузер запомнит на какое-то время, но после рестарта браузера оно потрется.

Все другие кастомные хедеры которые ты будешь создавать - их нужно явно в JS слать с каждым запросом. Браузер их не будет добавлять автоматически. И это не то как мы обычно реализуем аутентификацию.

авторНу вот, именно по такому принципу у меня и было организовано. Просто я переименовал стандартное имя "Authorization" в своё.Ну и приходилось опять же - самому слать этот хедер. Authorization браузер без нашего участия может слать. Но это совсем другой тип авторизации где нет сессии (браузер шлет Authorization с кредами каждый раз) и его редко используют.
авторСоответственно, можно и дальше использовать магию спринга, но при этом ключ сессии брать не из своего кастомного хедера "My-X-Auth", а из SESSIONID.Да, можно спрингом, можно самому написать. Но наверно надежней все-таки спрингом :)

авторИ потом как-то продлять если надо, или она автоматически продляется с каждім запросом.Да, автоматически. В куках есть expiration - браузер считает его от последнего запроса на сервер.
авторСоответственно, можно и дальше использовать магию спрингаЭто не должно быть магией - попробуй подебажить спринговые фильтры/интерсепторы да разобраться где там что.
авторДа, но у нас в барузере есть различные storages, где мы можем хранить этот ключ, ну а уже на сервере продлять(ttl)/удалять этот ключ и сессию автентификации.Угумс. Cookies по сути это еще один такой storage. Проблема с твоими другими storage'ами - к ним есть доступ у JS, а это не безопасно. Потому как если у тебя будет бага и тебе сделают HTML Injection (aka XSS), то злоумышленник может получить доступ к этому хранилищу и у знать твой SESSIONID (например, его JS возьмет и незаметно пошлет SESSIONID в посте этого форума, ну а там уже останется только скопировать).

А вот в Cookies можно задавать флажки при изначальном их создании. Одним из них есть HttpOnly (советую прочесть всю страницу) - он значит что такая кука будет передаваться браузером, однако JS не будет иметь к ней доступ.

Открой ради интереса Web Developer в своем браузере (обычно открывается с помощью F12), и посмотри на вкладку Application. У этого форума есть несколько кук, включая ASP.NET_SessionId, у нее проставлен HttpOnly.