JWT и Session: как правильно использовать JWT вместо Session

Question

Я работаю над проектом с PHP и Angular.Для входа пользователя мы используем JWT.До сих пор не могу понять, почему мы должны использовать JWT вместо сессий, если каждый раз, когда пользователь просматривает компонент, нам нужно отправить токен на серверный код, чтобы проверить, вошел ли пользователь в систему или нет.

Имя пользователя и пароль будут отправлены на серверный код, где будет происходить процесс аутентификации, а затем сгенерировать токен и отправить его обратно в angular, а затем сохранить в локальном хранилище.

Любой комментарийкак правильно использовать JWT.

EDIT

Мой вопрос касается процесса проверки JWT, когда пользователь просматривает сайт и переходит из одного компонента в другой.

Answer 1

Ваш JWT уже является доказательством вашей аутентификации.Таким образом, вы должны отправлять его с каждым запросом, но вы можете упростить логику аутентификации на стороне сервера.

При входе в систему вам придется проверять учетные данные, на которые вы можете полагаться в подписи JWT и expiryDate.Если подпись все еще верна, токен действителен, и вам больше не нужно проходить аутентификацию.

То же касается вашей горизонтальной аутентификации.Если вызываемая служба должна быть аутентифицирована, вы должны проверять правильность JWT для каждого запроса (обычно работает достаточно быстро).Если есть открытые вызовы API, вы, конечно, можете игнорировать JWT на стороне сервера.

В конце дня нет никакой разницы для вашей «сессии», которая также отправит некоторый «секретный» ключ, который отображает вашконтекст сеанса.Следовательно, это также будет подтверждено.Для некоторых бэкэндов вы также можете использовать JWT в качестве ключа сеанса, чтобы задействовать оба мира.

Пример:

Допустим, у вас есть два корня API:

api/secured/*
api/open/*

(Обратите внимание, что secured и open здесь только для демонстрационных целей)

Часть secured будет содержать все службы, которые вы хотите аутентифицировать.Часть open может содержать нечувствительные данные, а также ваши службы входа в систему:

api/open/login -> returns your token
api/open/token/* -> refresh, check re-issue whatever you might need

Теперь предположим, что пользователь заходит на ваш сайт.Вы захотите указать ошибку аутентификации, если он попытается получить доступ к любому api/secured/* URL-адресу без надлежащего JWT.В этом случае вы можете перенаправить его на ваш логин и создать токен после его аутентификации.

Теперь, когда он вызывает URL api/secured/*, ваша клиентская реализация должна предоставить JWT (Cookie, заголовок запроса и т. Д.)...).В зависимости от вашей структуры, языка и т. Д. Теперь вы можете предоставить перехватчик / фильтр / обработчик на стороне сервера, который проверит:

1. Если JWT присутствует
2. , если подпись действительна(в противном случае токен был подделан)
3. если JWT все еще действует (expiryDate)

Тогда вы можете действовать соответственно.

Итак, подведем итог: Естьне нужно «аутентифицировать», если вы не хотите создавать новый токен.Во всех остальных случаях достаточно проверить действительность вашего JWT

Answer 2

Если вы используете сеанс для своего приложения ... Тогда, когда горизонтальное масштабирование совместного использования данных сеанса становится бременем ... вам либо нужен специализированный сервер ... JWt не имеют состояния и не имеют такого требования.Он содержит следующие данные

Заголовок - информация об алгоритме подписи, типе полезной нагрузки (JWT) и т. Д. В формате JSON

Подпись - ну ... подпись

Полезная нагрузка - фактические данные (или заявки, если хотите) в формате JSON