Защита rest api с помощью jwt

#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 */ );

});
  

Способ аутентификации пользователя тогда будет:

  1. Убедитесь, что api-key он действителен.
  2. Проверьте if(!user.session){ // Route to login page. }
  3. Проверьте if(!user.session.token){ // Not authorized. }
  4. Проверка user.session.token
  5. Используя учетные данные внутри токена (НЕ вводите здесь пароль пользователя), подтвердите, что пользователь является действительным пользователем в вашей системе — при условии, что он зарегистрировал учетную запись на вашем веб-сайте / платформе. Вы можете, например, хранить уровни разрешений и идентификаторы пользователей с адресом электронной почты или что-то, что вы будете использовать для проверки.

Я надеюсь, что это поможет! Требуется некоторое время, чтобы обернуть ваши методы проверки подлинности head.

Комментарии:

1. да, это мне немного помогло. попытается выполнить аутентификацию api без участия пользователя, чтобы вы могли использовать api в приложении, но каждый пользователь этого приложения имеет к нему доступ

2. Помните, что вы хотели бы, чтобы пользователь вошел в систему, прежде чем он получит доступ к API, иначе любой посторонний человек сможет использовать Postman, например, и получить доступ к конечным точкам.

3. но зачем использовать токены, если вы все равно храните их на своем сервере? Если вы это сделаете, вы можете просто использовать сеансовые файлы cookie. И я почти уверен, что вы можете декодировать полезную нагрузку своих токенов, но вы не можете извлечь из этого «суперсекретный». Это отличная статья для лучшего понимания токенов: auth0.com/blog /…