Можно ли проверить запрашивающего пользователя для REST-транзакции, защищенной JWT, позднее?

У меня есть одностраничное приложение на React (Javascript), которое аутентифицирует пользователей через имя пользователя/пароль/MFA в Keycloak, получает подписанный JWT при успешной аутентификации, а затем использует этот JWT для вызова безгосударственных/безсессионных REST-сервисов.

С такой настройкой, или с дополнительными “подвижными частями”, которые могут быть добавлены в общую систему, есть ли способ позже убедиться, что определенная личность пользователя несет ответственность за транзакцию? Предположим, что мы можем сохранить любые/все данные, которые находятся в контексте (т.е. являются частью REST-вызова для транзакции) в момент, когда транзакция запрашивается.

Спасибо @alnbhclyn за их мысли ниже. Я думаю, мне нужно прояснить — ключевой пробел выше, похоже, заключается в связи между JWT и конкретным содержимым транзакции. Есть ли средство “подписать” транзакцию с помощью JWT или какой-либо его части, чтобы можно было в любой момент в будущем установить положительную связь между ними?

У вас уже есть подписанный токен JWT, если ваш HTTP-сервер сохраняет журналы доступа (и в этих журналах также есть куки), да, вы можете позже найти личность.

Убедитесь в следующих пунктах;

• Вам нужен секретный ключ JWT (который есть в этих куках).
• Какой алгоритм для этого подписанного куки JWT.
• Когда вы откроете эти куки, сможете ли вы идентифицировать конкретного пользователя или только увидите GUID, который будет сохранен в базе данных и позже удален? Например, некоторые разработчики создают таблицу сеансов и хранят открытые сеансы в этой таблице, JWT имеет идентификатор сеанса, и на последнем этапе при выходе удаляет строку из таблицы; если это так, JWT не решит вашу проблему. Вам нужно видеть идентификатор пользователя в ваших данных JWT.

Вы можете открыть токен JWT и увидеть, что вы на нем храните, вы можете использовать этот https://jwt.io/ сайт для этого.

Примечания к ведению журналов доступа;

• Журнал доступа хранит только URL, HTTP-код состояния, метод, куки, User-Agent и подобные данные, и не хранит POST данные, поэтому если ваша конечная точка понимает действие по параметру POST, журнал доступа не сможет идентифицировать действие.
• Для Nginx и Apache HTTP-демонов включена конфигурация журналов доступа, IIS по умолчанию не имеет включенной конфигурации журналов доступа, вам нужно настроить это.
• Если вы будете использовать эти данные в SIEM, токен JWT станет проблемой, храните свои собственные журналы для SIEM (если собираетесь использовать).