Понимание авторизационной части JWT и сессии

Question

Итак, я прочитал о том, как выполняется аутентификация с использованием JWT, где мы в основном проверяем, является ли токен действительным, используя закрытый ключ (предполагая, что RSA является алгоритмом). И если токен действителен, то пользователь считается аутентифицированным.

И я также читал об аутентификации сеанса, где мы проверяем, существует ли предоставленный пользователем идентификатор сеанса (через cook ie), в хранилище сеансов (при условии, что mysql / redis используется для хранения сеанса). Если он существует, то пользователь считается аутентифицированным.

Но как мы используем JWT и сеанс для авторизации? Давайте рассмотрим действие, такое как GET invoice, при котором пользователь может просматривать только свой счет-фактуру.

Если мы считаем, что пользователь уже аутентифицирован,

как мы можем проверить, если пользователь авторизован, если мы используем JWT?

А как нам это сделать для сессии?

Answer 1

Вы, вероятно, путаете вещи. Одно из преимуществ использования JWT состоит в том, чтобы избегать ведения сеансов, которые имеют большой bottle масштаб при масштабировании.

JWT (Json Web Token) несет всю информацию, которая потребует его для аутентификации. нужно поддерживать сессию. Каждый HTTP-запрос к серверу будет содержать JWT, который будет содержать необходимые пользовательские утверждения, включая подпись. На сервере вы проверите подпись, чтобы проверить, является ли токен действительным или нет. Вы можете проверить токен, не поддерживая ни одного сеанса, и существует несколько способов сделать это.

Поскольку JWT по сути является объектом Json (Заголовок, Тело, Подпись), вы можете вносить заявки (электронные письма, роли, профиль и т. Д. c) в тело JWT. После проверки токена вы можете извлечь заявки, включая любые роли, и проверить, авторизован ли пользователь для доступа к ресурсу.

Вы должны посмотреть Open ID Connect и токены здесь