ну пароль не стоит там хранить. он же открыт.

Блин я говорю о том когда там зашифрован пейлоад

так, как я понял, его никто не шифрует. По дефолту, во всяком случае.

всмысле claim какой-то зашифрован или че?

Ибо тогда вопрос звучит - можно ли не зашифрованные приватные данные отправлять на клиент, ну и очевидно что нет

не для всех очевидно, некоторые думают, что пейлоад зашифрован.

Ну никто не мешает туда зашифровать что-то и положить, что угодно и как угодно

никто не мешает да, но пароль все равно не рекомендуется держать в токене

неважно в каком виде

Ну так я и говорю, что либо шифровать без возможности что-то вытащить оттуда, либо не секьюрно

вот про это я и хотел узнать. Делает ли так кто-то и если да, то зачем? По мне, так ничего приватного в токене хранить не надо, шифровать не надо, проверил подпись и ок. Но может есть какие-то кейсы, с которыми я не сталкивался, тем более про токены с зашифрованным пейлоадом где-то читал.

И в первом случае вообще тогда нет смысла

Есть же сопутсвующий JWT стандарт - JWE - это как раз про энкрипшин JWT токенов.
JWT - это просто стандарт формата данных (и некоторые стандартные claims). Его юзать можно для чего угодно, а не только лишь для аутентификации/авторизации. Поэтому если даже в большинстве случаев JWE не используется, это не значит, что о не используется вообще никогда.

да все зависит от того - что за данные, какая стратегия по безопасности, насколько критична утеря токена, и так далее. что-то можно зашифровать дополнительно и положить в токен в payload - этоже просто ключ-значение(пусть и зашифрованное значение), стандарт это позволяет - но не биографию Толстого же )  и не список квартир и машин и банковских счетов )))

Почему нет смысла? JWT не обязательно расшифровывать на клиенте. Даже скажу больше - в основном никто на клиенте его не расшифровывает (если говорить об использовании JWT в качестве механима авторизации (access_token)). С точки зрения клиента он рассматривается как opaque string, не более. Смысл использовать все еще есть - чтобы снизить зависимость между resource server и auth server, а так же нагрузку на auth server. Без JWT каждый приходящий к resource server запрос нужно аутентифицировать, сделав внутренний запрос к auth server. С JWT это делать не обязательно (хотя иногда все равно делают, чтобы проверить, не отозван ли токен раньше expired date и т.п., когда безопасность важнее скорости работы, но тогда действительно смысл частично теряется).

Есть еще id_token (если говорить уже о стандарте OIDC, который описывает уже не просто формат (JWT), а еще и семантику), вот он как раз предназначен для клиента.

Ну и, опять же, сам формат JWT не привязан ни к access_token, ни к id_token. Его можно использовать для чего угодно. И далеко не всегда необходимо, чтобы клиент что-то из него получал. Так что нельзя так сказать, что если токен зашифрован, и клиент оттуда, соответственно, ничего получить не может, то такой токен нет смысла гонять на клиент. Смысл вполне может найтись.

Я про пейлоад только

Так и я про пейлод. Зашифрованный пейлоад например может расшифровать ресурс-сервер (а получил его клиент от auth-сервера)

Ну так клиенту он не нужен, я говорю сейчас про ui клиент

Это понятно, я говорил про вот это ваше утверждение.

Смысл вполне может быть. Клиент получает от аутх-сервера токен с таким вот пейлоадом, а отправляет потом на ресурс-сервер. Сам клиент не может посмотреть значение пейлоада, но при этом этот пейлоад таки "гоняется на клиент".