Все зависит от того кто и как будет обращаться к backend.
Если это другой сервер, мобильное приложение или SPA то лучше использовать токены - JWT как самый распространенный вариант.
В случае обычного сайта или SPA возможно использовать сессии.
Если используем обычные статические страницы + http api тогда сессия вполне нормальный вариант в том числе и для приложения по типу web-view.
Если используем SPA с REST api / Graphql тогда токены удобнее.
Что касается где хранить id пользователя в токене то самом JWT есть заголовок для этого. Вообще Jwt это 2 json + хэш/ключь слепленные вместе через base64.
Первый json - служебный в нем идет алгоритм и тип ключа, второй - настраиваемый и может содержать что угодно, правда для некоторых моментов например id токена (jti) или id сессии (sid) есть предопределенные заголовки. Полный их список
тут
В вашем случае есть 2 варианта
1 - доступ по сессии
API и SPA требует сессию для защищенных методов, авторизация эту сессию предоставляет. Авторизация - может быть выполнена как обычной статической html с формой так и отдельным SPA.
2 - доступ по токену
В этом случае Авторизация реализуется в виде api на стороне сервера, и в виде токена
+ формы + логики авторизации на стороне клиента (Vue). Если токен есть - тогда есть доступ, если нет - то доступ только к методам регистрации и авторизации.
Чтобы не палить код той части приложения где есть логика и фронт закрытой части - можно использовать code-splitting - сперва подгружается форма авторизации а остальное грузиться тогда когда это нужно.
Есть правда еще более извращенные варианты вроде SPA с SSR на том-же Nuxt/Next/Express где пользователю токен а бэку на Go/JAVA/PHP уже токен приложения + токен пользователя.
Иногда стоит использовать OAuth2.0 и LDAP которые тоже довольно интересны.
Первый хорош на все случаи жизни, но только если используется куча связанных приложений/микросервисов а второй просто рай для бизнес-пользователей с Windows для какой-нибудь коробочной CMS.
Средний
