Что нужно проверить в отношении утверждений «iat» и «sub» JWT? - PullRequest
0 голосов
/ 06 апреля 2020

Я пишу SSO-сервер аутентификации на Node.js и Express, используя JWT для аутентификации. Я читал статьи из таких источников, как Auth0, о том, как лучше защитить свои JWT. Мне удалось включить и проверить большинство стандартных утверждений для токена, но мне интересно, что именно нужно проверять утверждения «iat» и «sub» против.

Для «iat», когда токен передается на маршрут Express, и этот маршрут начинает проверять состояние проверки подлинности пользователя перед выполнением каких-либо конфиденциальных операций. Каков наилучший способ предоставления значения для проверки этого утверждения? Моим лучшим предположением было извлечь userId из токена, прежде чем проверять подпись, а затем сравнивать ее со значением 'iat', которое будет храниться в таблице пользователей, но это не так.

Для 'sub', с сервером без состояния, как приложение должно знать, на какое требование 'sub' пользователя ожидать и проверять, если приложение получает информацию о своем пользователе от самого проверенного токена?

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

1 Ответ

1 голос
/ 07 апреля 2020

Чтобы JWT работал, приложение-потребитель должно иметь возможность доверять серверу выдачи SSO / JWT. Когда выдающий сервер генерирует токен и криптографическая подпись c была проверена, утверждения по своей сути верны. Вы все равно должны проверить все входные данные в токене, чтобы убедиться, что они обоснованы.

Заявка, подобная iat, - это сервер-эмитент, записывающий время, когда он сгенерировал токен. Если предположить, что это допустимое разумное время (не 1970), то тот факт, что сервер-эмитент указал это и подписал его, можно рассматривать как факт.

Примечание. Значения заголовка alg и typ всегда должны быть проверяется как совпадающее со значениями с сервера выдачи перед проверкой подписи.

Выдано в

iat: Указывает время, когда был выпущен JWT. Значение должно быть Numeri c Date.

Возможная проверка:

  • Действительное положительное целое число
  • В прошлом
  • Отметьте это новее, чем вы в последний инцидент безопасности (быстро отозвать все возможные скомпрометированные токены)

Тема

sub: Идентификация субъекта JWT. (Это имя пользователя / имя / идентификатор пользователя)

Возможная проверка: - Он существует, не пустой - Пользователь существует и не заблокирован и т. Д. c в базе данных. (необязательно в зависимости от того, как вы сохраняете состояние)

...