Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.
Так конечно никто не делает, есть понятия аутентификации и авторизации, сессия устанавливается после аутентификации (пользователь подтверждает что он - это он) и потом этот пользователь авторизуется с каким-то правами и в сессию каким-нибудь подходящим образом ставятся атрибуты авторизации, в простейшем случае - роль пользователя (админ/юзер). Эти атрибуты фронт может запросить у бэка отдельным запросом или получить в ответе на /login.
Не очень понятно что значит "запрос для входа пользователя" и "запрос для входа менеджера" -
у вас предполагается что пользователь будет нажимать на разные кнопки "войти как менеджер" и "войти как пользователь" или что?
Нормально так:
Кнопка для логина - одна.
запрос аутентификации - один.
сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.
Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.
Можно сделать и более сложные варианты - без куки, с каким-нибудь токенами и прочим, но скорее всего вашему фронтэндщику еще рано.
