Что верно про использование JWT для аутентификации?

Устройство. Заголовок, полезная нагрузка (claims) и подпись, каждая часть в base64url. Сервер проверяет подпись своим ключом и не ходит в базу — это хорошо масштабируется и удобно между сервисами (особенно с асимметричной подписью RS256/ES256: проверять может любой по открытому ключу).

Ловушки:

• отзыв — выход пользователя, смена пароля, блокировка не отменяют уже выданный токен. Решения: короткий срок жизни access (5–15 минут) и refresh с сервером-хранилищем, который можно отозвать; чёрный список id токенов (jti) — но это снова поход в хранилище;
• открытый payload — его прочитает любой; персональные и секретные данные не кладут;
• алгоритм — проверять с явно заданным ожидаемым алгоритмом. Иначе атакующий ставит alg: none или подписывает HS256 открытым ключом, который библиотека примет за секрет;
• размер — токен уходит с каждым запросом; не раздувать claims;
• проверка полей — exp, nbf, iss, aud.

Где хранить в браузере — симметричный выбор:

• httpOnly-cookie — скрипт не прочитает (защита от кражи через XSS), но браузер сам отправляет cookie — нужна защита от CSRF (SameSite, токен);
• localStorage / память — CSRF не страшен, но любой XSS украдёт токен.