Как получить jwt токен внутри метода с атрибутом AllowAnonymous?

Question

[Dudder]

Если для доступа к эндпоинту требуется авторизация через заголовок в котором указывается jwt токен доступа, то я могу спокойно получить его значение и обратиться к Claims где хранится id пользователя

var userId = context.HttpContext.User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier)?.Value;
var token = await HttpContext.GetTokenAsync(JwtBearerDefaults.AuthenticationScheme, "access_token")

Но в методе с атрибутом AllowAnonymous все будет null

Comments

[Rsa97]

А зачем получать id пользователя в методе, не требующем идентификации пользователя?

[Dudder]

Rsa97, У меня есть эндпоинт refresh, к нему клиент обращается когда эндпоинты, которые требуют токен доступа, возвращают статус код 401 и клиент запрашивает refresh, у токена доступа в Claims записан id пользователя, я его беру и из бд извлекаю refresh token пользователя. Не буду полностью расписывать принцип работы этого эндпоинта, но суть должна быть ясна

[Rsa97]

Dudder, А что мешает записать id пользователя в refresh-токен и не ставить AllowAnonymous?

[Dudder]

Rsa97, 1. Это мне нужно извлекать из каждой записи в бд строку refresh token, брать из нее Claims и извлекать id, не знаю на сколько это будет нагружать бд. 2. Эндпоинт все равно будет AllowAnonymous, так как он вызывается только тогда, когда токен доступа просрочен. С атрибутом Authorize он не будет выполняться при просроченном токене

[Rsa97]

Dudder, Зачем? Refresh-токен это такой-же JWT, только в нём немного другая информация, как правило только uid токена и id пользователя.

[Dudder]

Я немного не понял, как я узнаю id пользователя который обращается к refresh?

[Dudder]

Rsa97, Объясните немного подробнее Ваш подход, пожалуйста

[Rsa97]

Dudder, Вы знаете, что такое JWT? Это структура из трёх частей - заголовка, полезной нагрузки и подписи. Так в полезную нагрузку можно вписать что угодно.
В качестве refresh-токена чаще всего используется тот же JWT, только в полезной нагрузке у него минимальная информация, достаточная для выдачи новой пары токенов. Обычно это uid токена и id пользователя. Uid используется для проверки, что по данному токену ещё никто не обновлялся.

[Максим Федоров]

то я могу спокойно получить его значение и обратиться к Claims где хранится id пользователя

и что вам это дает? если вы не владелец системы... id пользотвалея не дает вам досутпа ни к чему, а еще это может быть открытая информация, например email

[Роман]

Dudder, вообще то, токен надо обновлять до его истечения.

[Voland69]

Dudder, когда клиенты с истекшим АТ получили 401, это значит что авторизация не прошла - и в методе с AllowAnonymous, если вы передаете токен, Identity.IsAuthenticated тоже будет false у юзера, т.к. время жизни токена истекло.
Как я поступал в подобной ситуации: на RefreshUrl отправляем модель с AT и RT, плюсом один из клеймов AT - SessionId.
Для разбора AT написан свой хелпер, который создает JwtTokenHandler с настройками, идентичными AddAuthentication, но с отключенной проверкой времени жизни токена.
В данной схеме RT - не JWT, а просто уникальный идентификатор, который при рефреше меняется - чтобы не получить два рабочих AT на сессию.

Как вариант можно сложить все нужные клеймы в RT (тоже JWT), тогда отправлять AT клиенты не должны вовсе, но свой TokenHandler для разбора RT и извлечения клеймов вам все равно понадобится.

[Voland69]

Роман, поясните мысль, пожалуйста. Например в ситуации, когда клиент не делал запросов за период времени ATLifetime < Tau < RTLifetime (человек не обновлял страницу, не нажимал кнопок и т.п.), как тогда следует поступать?

[OwDafuq]

Лично у нас сделано так, что Refresh живет независимо от JWT, JWT живет как правило несколько минут, а Refresh может жить хоть год. Поэтому у нас сделано так, что после недели неактивности можно по Refresh'y взять новый JWT и продолжать работать. Refresh'и держим в базе, при попытке обновить JWT по Refresh'y - смотрим в базу и строим новый JWT. Имхо, но нет смысла держать в Refresh'e данные, т.к. за время жизни JWT и Refresh'a могут поменяться данные человека, в т.ч. роли, имя, почта и прочее, иногда эти данные нужны в JWT.
Поэтому вам не обязательно получать никакие данные от пользователя, достаточно сам Refresh token, а по нему в базе посмотреть кто его запрашивает и выдать новый JWT. (ИМХО(!))

[Dudder]

OwDafuq, У меня буквально так и реализовано, в refresh хранится только id пользователя

[OwDafuq]

Dudder, если честно - не понимаю зачем в нем что-то хранить в целом, время жизни у Refresh'a тоже должно быть время жизни, в базу полезете всё равно, а там можно и связь на таблицу пользователей сделать