Итак, я реализовал некоторую форму аутентификации в своем API, я не уверен, к какому типу она относится.
Что делает мое приложение, так это то, что оно генерирует токен, как только пользователь регистрируется/входит в систему, а затем перед каждым вызовом конечной точки у меня есть функция промежуточного программного обеспечения, которая проверяет, существует ли токен, затем расшифровывает его, и если он правильный, то сохраняет пользователя информация в req.user
. Затем я использую информацию о пользователе в req.user
для других вещей позже.
Классифицируется ли это как аутентификация на основе токена?
Я посмотрел в Интернете и прочитал, что вместо того, чтобы хранить токен в виде файла cookie на стороне клиента, если я сохраняю информацию о пользователе на стороне сервера в виде сеанса и идентификатор сеанса в виде файла cookie на стороне клиента, он классифицируется как аутентификация на основе сеанса.
Таким образом, ясно, что мое приложение имеет аутентификацию на основе токена, верно?
(Извините, если я ищу разъяснения по очень простым вещам, я очень новичок)
Вы пишете, что «проверяете, существует ли токен», и я предполагаю, что это означает, что вы ищете его в базе данных. Это похоже на экспресс-сессию, где файл cookie содержит токен, а сессия также просматривается в базе данных. Разница может заключаться в том, что вы передаете свой токен не в файле cookie, а в заголовке запроса (вы не говорите, какой метод вы используете).
Однако одним из важных аспектов авторизации на основе токенов является то, что токен не нужно искать в базе данных, а можно полностью проверить в памяти, проверив подпись. Это быстрее и потребляет меньше ресурсов. Особенно, если ваш сервер получает много (вредоносных) запросов с недопустимыми токенами, он может обнаружить и отклонить их, не загружая базу данных. См. также ответ на Некоторые вопросы о токенах обновления.
Вы можете комбинировать это с подходом на основе сеанса, если идентификатор сеанса также содержит подпись, и это проверяется перед поиском сеанса в базе данных.
Узнайте больше о подписанных токенах и проверке подписи под тегом jwt.
@ user13387446: Но вы не можете просто удалить пользователя из req.cookies
без предварительной проверки файла cookie. Клиент помещает любой файл cookie, который ему нравится, в запрос и, таким образом, может выдавать себя за любого пользователя, если файл cookie не проверен. Ваш файл cookie подписан?
Сначала я проверяю, действителен ли токен в req.cookies
, если он действителен, я сохраняю информацию о пользователе в req.user
Затем он основан на токене: действительность запроса подтверждается только токеном.
Да, вы реализовали аутентификацию на основе токенов в своем сценарии, сеанс на основе совершенно другого подхода, который вам нужно хранить сеанс в вашем бэкэнде, чтобы отслеживать, является ли клиент действительным или нет, но на основе токенов вам не нужно хранить сеансы, но у вас будет два токена: ТОКЕН ДОСТУПА и ТОКЕН ОБНОВЛЕНИЯ, и вам нужно будет хранить токен обновления в базе данных на случай будущей регенерации токена доступа, вот как работает аутентификация на основе токенов!
Извините, если я кого-то запутал, по «проверить, существует ли токен» я смотрю, есть ли токен в
req.cookies
. Я не получаю доступ к БД здесь, верно?