JWT не подходят для поддержания сессии пользователя. Они для этого не созданы, это небезопасно, и есть гораздо лучший инструмент — обычные cookie-сессии.
JWT создавали только для очень короткоживущих токенов — на пять минут или меньше. Сессии должны жить дольше. Stateless-аутентификация в безопасном виде практически нереализуема. Если всё равно нужна база данных для хранения токенов, проще хранить в ней все данные сессии. JWT, который хранит обычный идентификатор сессии — это неэффективно и менее гибко, чем обычная cookie-сессия, и не даёт никаких преимуществ.
Спецификации JWT не доверяют эксперты по безопасности. В оригинальной спецификации была заложена возможность создавать поддельные токены, и там наверняка есть другие ошибки. Надеяться на JWT в вопросах аутентификации не стоит.
Отдельная проблема — localStorage. Хранить там любые данные для аутентификации, включая JWT-токены, нельзя.
Да, Google использует JWT. Но не для пользовательских сессий в браузере. У Google обычные cookie-сессии. JWT они применяют сугубо как транспорт для Single Sign On — чтобы перенести сессию с одного сервера или хоста на другой. Это разумное применение, и у Google есть ресурсы и эксперты, чтобы сделать свою реализацию JWT более безопасной. Их JWT — это фактически не то же самое, что у всех остальных.
Аргумент «stateless — это лучше» не работает. Без огромных ресурсов защищённую stateless-аутентификацию не сделать. Stateless — это миф.
Если нужно настроить сессии: документация любой веб-фреймворка проведёт весь процесс. Почти любой фреймворк содержит готовую реализацию сессий, её легко включить. Express и другие Node.js фреймворки — исключение из-за своей модульности. Для Express нужно подключить middleware express-session и соединитель с хранилищем, например connect-session-knex для Postgres, MySQL или SQLite.
Если всё-таки нужен короткоживущий подписанный токен, есть спецификация PASETO — она изначально спроектирована безопасной. Только не используйте её для сессий.