Node js, токен JWT и логика, лежащая в основе

Я использую JWT для защиты URL-адресов узлов js https://github.com/auth0/express-jwt

Чтобы создать сеанс пользователя токена JWT, я просто делаю:

-> auth/signup
    -> jwt.sign(user_profile,secret,expireInMinutes:{900000000 /*almost never expires*/});

ИЛИ в случае входа в систему

 -> auth/login
        -> jwt.sign(user_profile,secret,expireInMinutes:{900000000 /*almost never expires*/});

Каждый раз, когда вызывается защищенный URL-адрес, я проверяю req.user, который автоматически настраивается промежуточным программным обеспечением JWT.

Теперь мне интересно:

1 - где хранятся токены JWT при вызове sign ()?

2 - должен ли я проверять () токен каждый раз, когда вызывается защищенный URL-адрес? если да, то почему?

3 - Когда я устанавливаю новый токен для уже подписанного пользователя, удаляется ли старый токен (если существует)? Что делать, если срок действия не установлен или составляет, например, 5 лет?

4 - Почему я не могу установить новые токены на той же странице браузера / приложения? Я получаю ошибку неверной подписи, если я регистрирую новый токен, но токен совпадает (я проверил). Это похоже на то, что я не могу войти более 1 пользователя в один и тот же браузер.


node.js javascript jwt express express-jwt
person itsme    schedule 20.02.2014    source источник

Ответы (4)


arrow_upward
17
arrow_downward

Вы, должно быть, уже догадались ответы на все свои предыдущие вопросы, используя предыдущие ответы других пользователей, но я постараюсь немного прояснить ситуацию и для других:

1 - где хранятся токены JWT при вызове sign ()?

Когда вы позывной, подписанный токен нигде не сохраняется, он возвращается функцией знака, затем вы должны отправить его клиенту, чтобы он мог быть сохранен на стороне клиента. (например, хранилище сеанса, локальное хранилище или файл cookie)

2 - должен ли я проверять () токен каждый раз, когда вызывается защищенный URL-адрес? если да, то почему?

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

3 - Когда я устанавливаю новый токен для уже подписанного пользователя, удаляется ли старый токен (если существует)? Что делать, если срок действия не установлен или, например, составляет 5 лет?

Слегка связано с ответом по пункту 1. Вызов функции знака просто сгенерирует еще один токен. Срок действия токена хранится в самом подписанном токене. Таким образом, каждый раз, когда сервер получает токен от клиента, он проверяет срок его действия как часть проверки токена. Важно отметить, что подписанный токен - это просто объект user_profile, который вы передали в качестве параметра во время подписания, плюс дополнительные поля, такие как дата истечения срока действия, которые добавляются к этому объекту.

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

4 - Почему я не могу установить новые токены на той же странице браузера / приложения? Я получаю ошибку неверной подписи, если я регистрирую новый токен, но токен совпадает (я проверил). Это похоже на то, что я не могу войти более 1 пользователя в одном браузере.

Идея состоит в том, чтобы на каждый браузер приходился 1 пользователь. Поскольку в этом случае браузер является клиентом. Я не могу вспомнить случаи использования, когда вам нужно было бы иметь несколько пользователей на браузер / клиент, поэтому вы, очевидно, делали что-то не так. Это не значит, что невозможно отправить несколько токенов одному и тому же браузеру / клиенту.

person Alappin    schedule 17.06.2014

arrow_upward
8
arrow_downward

  1. Вам необходимо хранить токен на стороне клиента (локальное хранилище или файл cookie)

  2. да. HTTP не имеет состояния. Если вы не проверяете его каждый раз, кто-то может вызвать ваш URL без токена или с недействительным токеном. Если вас беспокоит производительность, проверка HMACSHA256 выполняется очень быстро.

  3. Это не имеет смысла, вы, должно быть, делаете что-то не так.

person woloski    schedule 20.02.2014
comment
спасибо, для пункта 3/4 я решил, что это моя собственная ошибка, кажется;) по поводу пункта 2: зачем проверять? я имею в виду, URL-адреса / api уже защищены, нет? мне нужно добавить в них дополнительную проверку jwt? - person itsme; 20.02.2014
comment
Я имею в виду, что я попытался вызвать защищенный URL-адрес / api с ручным заголовком, например, authorization: Bearer random_hand_made, и он правильно возвращает {message: Invalid token: no header in signature 'kerkgekrgkerkgekrgkergkerkg', code: invalid_token , статус: 401, внутренний: {}}} разве не достаточно? - person itsme; 20.02.2014

arrow_upward
3
arrow_downward

2 - должен ли я проверять () токен каждый раз, когда вызывается защищенный URL-адрес? если да, то почему?

да. Но «проверить» - это немного сбивающий с толку термин.

  1. Когда клиент вызывает / аутентифицируется, сервер сначала проверяет учетные данные пользователя в базе данных, чтобы сделать этого пользователя аутентифицированным. Причем эта «дорогостоящая» операция выполняется всего один раз за всю жизнь токена. Затем сервер подготавливает объект JSON, содержащий полезную информацию о пользователе, и шифрует его, чтобы получить токен JWT.
  2. Этот токен отправляется клиенту только один раз, сохраняется в браузере, а затем отправляется обратно на сервер при каждом клиентском запросе к / api.
  3. Во время обработки запроса client / api сервер должен «проверять» токен на валидность (JWT делает это за вас). Но это не означает, что нужно снова проверять учетные данные пользователя по базе данных. Достаточно просто расшифровать токен, чтобы вернуть объект JSON, проверка HMAC-SHA256 - довольно быстро.
  4. Имея объект JSON с полезной информацией о пользователе (утверждения), сервер может разрешить или запретить этому конкретному пользователю доступ к запрошенному ресурсу по маршруту / api.

Во время проверки токена проверка учетных данных пользователя в базе данных не требуется, поскольку сервер должен доверять полученному и проверенному (успешно расшифрованному) токену. Для идентификации пользователя хранилище сессий сервера не требуется.

Вы можете думать о токенах JWT как о простой информации о сеансе, хранящейся на клиенте в зашифрованном виде. Но если вам нужно кэшировать больше данных в информации о сеансе пользователя, я думаю, вам все равно нужно какое-то хранилище сеансов на сервере, что делает идею JWT почти бесполезной по сравнению с традиционным идентификатором сеанса в файлах cookie.

person rus1    schedule 01.09.2014

arrow_upward
2
arrow_downward

Извините. это должен быть комментарий к предыдущему ответу, но у меня недостаточно комментариев, чтобы прокомментировать, поэтому он идет

@sbaang: Еще одна причина для проверки каждый раз заключается в том, что в токене могут быть интересные "утверждения2", например, разрешение пользователю доступа к определенным конечным точкам, а не ко всем из них. Таким образом, при каждой проверке вы не только проверяете, разрешено ли пользователю для доступа к защищенному API, но к этой конкретной конечной точке, на основе не наличия действительного токена, а наличия токена, который специально это разрешает.

person mtsdev    schedule 01.06.2014