Полный ответ на ваш вопрос будет очень длинный, но вот моя попытка краткого.Сервер также является объектом, который в первую очередь выдает JWT.Таким образом, он обладает ключом , который использовался для подписи каждого исходящего JWT.В результате этого, когда сервер получает входящий JWT, он сначала пытается открыть / разблокировать этот JWT, используя свой закрытый ключ.Если JWT был каким-либо образом подделан, сервер может не открыть его должным образом, и это приведет к исключению.В качестве примера одной проверки работоспособности, которую сервер будет выполнять в отношении входящей JWT, он будет наблюдать контрольную сумму JWT, которая не пройдет в случае подделки.
Как только сервероткрыв JWT и посчитав его действительным, следующая вещь, которую он, вероятно, проверит, будет exp претензия , одна из, возможно, нескольких претензий, содержащихся в JWT.exp, или претензия с истечением срока действия, фиксирует срок действия JWT.Если пользователь представляет устаревший JWT, сервер немедленно отклонит JWT как недействительный.
До сих пор мы обсуждали проверки, которые сервер может выполнять, не используя состояние, то есть полагаясь только на содержащееся в нем состояние.в самом JWT.В действительности, большую часть времени сервер фактически хранит свое собственное состояние.В качестве примера того, почему это может быть необходимо, рассмотрим крайний случай пользователя, который выходит из сайта или приложения.В этой ситуации его телефон или браузер по-прежнему будут иметь JWT с действительным сроком действия exp.Чтобы пользователь не мог продолжать использовать этот JWT, сервер может поддерживать черный список JWT, который он не будет соблюдать, даже если проверка exp и контрольной суммы прошла проверку.Итак, третий шаг после разблокировки JWT и проверки exp может состоять в том, чтобы убедиться, что JWT не появляется в черном списке.
Хорошая реализация JWT может ограничить количество состояния на стороне сервера до чего-то оченьмаленький, но обычно сервер фактически поддерживает свое собственное состояние.