#node.js #rest #api #token
#node.js #rest #API #токен
Вопрос:
Я пытался защитить свой rest api с помощью аутентификации, чтобы только доверенные приложения могли использовать этот API. Я искал лучшие практики и руководства, но ни одно из них на самом деле не объясняет это на реальном примере.
Я создал аутентификацию jsonwebtoken, аналогичную этой:
if(!user){
res.json({success:false, message: 'auth failed, user not found'});
} else {
var token = jwt.sign(user, app.get('superSecret'), {
expiresIn: 1440 //24 hours
});
res.json({
success: true,
message: 'token generated',
token: token
});
}
Это работает нормально, возвращая токен, который я затем могу передавать со всеми запросами в api, но как мне заставить приложение находить этот токен и использовать его вместо того, чтобы вручную передавать токен при каждом вызове api?
Я видел, что в большинстве случаев вы можете сгенерировать специальный api-ключ в приложении и включить эту информацию в клиентское приложение, которое работает как токен, и нет необходимости запрашивать новый токен с сервера.
Как это работает или как мне создать ключи доверенных приложений для моей службы restful?
Ответ №1:
Использование JWT прекрасно, на самом деле я использую его сам. Но способ, которым вы используете его в своем примере, не очень безопасен. JWT не шифруются, а просто кодируются. Если вы отправляете этот токен кому-либо и включаете конфиденциальную информацию, такую как superSecret
, любой, у кого есть доступ к токену, сможет расшифровать это.
Более чистая идея — прикрепить этот токен к объекту сеанса. Если вы используете Node.js и только после этого вы сможете воспользоваться express-session
библиотекой. Это присоединяет объект сеанса к каждому запросу. После аутентификации пользователя вы можете назначить этот токен объекту сеанса и сохранить его либо в базе данных, либо в хранилище памяти, например redis
. Для дополнительного уровня безопасности вы можете создать api-key
для каждого доверенного приложения и сохранить его в своей базе данных. api-key
Может быть передан в качестве заголовка.
Для настройки сеансов с помощью Express, но я предлагаю вам ознакомиться с другими опциями и способами настройки этого в соответствии с вашими потребностями:
var session = require("express-session");
app.use(session({
secret: /* Your secret. */,
store: /* Your redis store object. */,
client: /* Your redis client object. */,
resave: false,
saveUninitialized: false
}));
Чтобы прикрепить access-token
к пользователю при входе в систему (например):
router.post("/login", function(request, response){
/* Do all user validation here */
request.session.token = jwt.sign({
/* User info to store in session. */
}, "superSecret");
return response.redirect( /* Dashboard */ );
});
Способ аутентификации пользователя тогда будет:
- Убедитесь, что
api-key
он действителен. - Проверьте
if(!user.session){ // Route to login page. }
- Проверьте
if(!user.session.token){ // Not authorized. }
- Проверка
user.session.token
- Используя учетные данные внутри токена (НЕ вводите здесь пароль пользователя), подтвердите, что пользователь является действительным пользователем в вашей системе — при условии, что он зарегистрировал учетную запись на вашем веб-сайте / платформе. Вы можете, например, хранить уровни разрешений и идентификаторы пользователей с адресом электронной почты или что-то, что вы будете использовать для проверки.
Я надеюсь, что это поможет! Требуется некоторое время, чтобы обернуть ваши методы проверки подлинности head.
Комментарии:
1. да, это мне немного помогло. попытается выполнить аутентификацию api без участия пользователя, чтобы вы могли использовать api в приложении, но каждый пользователь этого приложения имеет к нему доступ
2. Помните, что вы хотели бы, чтобы пользователь вошел в систему, прежде чем он получит доступ к API, иначе любой посторонний человек сможет использовать Postman, например, и получить доступ к конечным точкам.
3. но зачем использовать токены, если вы все равно храните их на своем сервере? Если вы это сделаете, вы можете просто использовать сеансовые файлы cookie. И я почти уверен, что вы можете декодировать полезную нагрузку своих токенов, но вы не можете извлечь из этого «суперсекретный». Это отличная статья для лучшего понимания токенов: auth0.com/blog /…