Вернемся к разделяемой логике. Куда класть модель управления данными используемыми сразу в нескольких страницах?
В методологии FeatureSlices это называется feature. Одна фича это переиспользуемый общий код относящийся к одной сущности. Этой сущностью может быть как бизнес-сущность(пользователь, блог-пост или рекламная кампания), а также техническая сущность (но лучше без таких).
В случае аутентификации и авторизации, бизнес-сущностью является текущий пользователь, так называемый viewer.
В фиче viewer может лежать все что нужно для работы с текущим пользователем: проверка прав доступа, компонент для этого, разделяемые данные этого пользователя, модели фонового обновления данных, завершение текущей сессии пользователя и т.п.
Но при этом, процессы входа(создания сессии) не являются фичей, так как не разделяются и не переиспользуются на разных страницах.
Ведь способов входа может быть достаточно много: по номеру телефона, email + password, email + link, вход после восстановления пароля, вход после регистрации. И в каждом из способов есть свой особенный флоу и код его реализующий.
FeatureSlices не является догмой или строгими правилами по которым нужно проектировать и разделять код. Это рекомендация, цель которой является упрощение разработки приложений.
Если в Вашем приложении имеются общие компоненты или код в процессах аутентификации, вполне можно вынести суб-процессы, отдельные компоненты, валидаторы и другое разнообразие кода в техническую фичу authentication.
Важный момент — документация. Стоит создать README.md для каждой фичи и накидать туда описание фичи, цели использования, мотивация для создания, доступные элементы, обслуживаемые процессы.
Главное не забывать просматривать документацию и сверять с актуальным состоянием, может нужно отрефакторить, чтобы соответствовать целям фичи. А может быть нужно обновить документацию.