2015-07-06 1 views
0

Я использую express.js, паспорт с jwt-стратегией и, конечно, jsonwebtoken для node.js.Некоторые основные вопросы о JWT (сервер и клиентская сторона)

Итак, в настоящее время мне удалось реализовать логику на стороне сервера, которая позволяет пользователям входить в систему и возвращать токен jwt.

После этого, когда я получаю запрос с соответствующим токеном в заголовке, он корректно проверяет токен jwt и отображает информацию. Код выглядит следующим образом:

var jwt = require('jsonwebtoken'); 

function createToken(user) { 
    return jwt.sign(user, 'shhhhh', { 
      issuer: "accounts.examplesoft.com" 
     }); 
} 

var opts = {}; 
opts.secretOrKey = 'shhhhh'; 
opts.issuer = "accounts.examplesoft.com"; 

passport.use(new JwtStrategy(opts, function(jwt_payload, done) { 
    console.log(jwt_payload); 
    User.findById(jwt_payload.id, function(err, user) { 
     if (err) { 
      return done(err, false); 
     } 
     if (user) { 
      done(null, user); 
     } else { 
      done(null, false); 
     } 
    }); 
})); 

app.post('/jwt_login', function(req, res) { 
    User._loginJwt({ 
     email: req.body.email, 
     password: req.body.password 
    }, function(err, user) { 
     if (err) res.json(err); 
     else res.json(createToken(user)); 
    }); 

}); 

app.get('/jwt_test', passport.authenticate('jwt', { 
    session: false 
}), function(req, res) { 
    res.json(true); 
}); 

Теперь я пытаюсь сделать клиентскую страницу. Я использую angularjs, и есть много jwt-библиотек для angularjs или, скорее, клиентской стороны в целом. Теперь у меня есть ряд вопросов:

  1. Прежде всего, это реализация на стороне сервера правильно (из чего вы можете узнать по коду выше)?
  2. Безопасно ли я хранить токен jwt в localStorage (на стороне клиента)?
  3. Почему так много библиотек доступно для клиентской стороны jwt? Не достаточно ли получить токен, а затем вызвать запросы с помощью этого токена? Что еще я мог сделать с этим токеном на стороне клиента?
  4. Не может ли кто-то просто скопировать токен jwt из localStorage и сделать запросы, как если бы они вошли в систему? Разве это не проблема безопасности?

Спасибо за ваши ответы!

ответ

2
  1. Реализация на стороне сервера выглядит хорошо, хотя заявки в токене могут быть расширены. Просто всегда удостоверяйте токен, и вы хороши.
  2. Да. Это часть того, почему JWT полезен. Если пользователь изменяет токен, он не будет соответствовать его сигнатуре и не будет проверять подлинность.
  3. Из того, что я помню, клиентский материал предназначен для передачи данных в полезной нагрузке, которая используется на клиенте. Вы хотите иметь возможность аутентифицировать токен на той стороне, а затем, поэтому ваш front-end не делает ничего, что он не должен.
    a. Если у вас просто есть RESTful API, который проверяет запросы с токеном, вам не нужно ничего делать с JWT на интерфейсе, кроме отправки его с запросами.
  4. Да. Вот почему ваш токен должен включать истечение в его требованиях. Имейте в виду, что единственный способ попасть в LocalStorage - это если они вошли в систему для начала.

Смотрите здесь для претензий, которые могут быть в вашем маркере:

http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#rfc.section.4

+0

Спасибо за быстрый ответ. По-вашему, вопрос, какие претензии могут быть добавлены в токен, по вашему мнению? Кроме того, как указано «Имейте в виду, единственный способ попасть в LocalStorage - это если они вошли в систему для начала». - пользователь всегда может вручную изменить localStorage, поэтому я не буду слишком полагаться на него. – uglycode

+0

Ну, вы всегда должны установить 'exp', чтобы убедиться, что токен истекает. Обычно я добавляю свои собственные претензии, такие как 'uid', чтобы проверить токен, соответствующий пользователю, которому я его назначил. См. № 2 о том, почему это не имеет большого значения, если пользователь сталкивается с JWT. – kiswa

+0

Да, я считаю, что я сделал то же самое, часть 'jwt_payload.id'. Еще раз спасибо! – uglycode