JWT - Как лучше всего использовать jsonwebtoken?я потерялся

Question

Я учусь кодировать уже год.В основном я научился работать с API отдыха (Node / Express на бэк-энде и Vue на фронт-энде).

Я дошел до того, что хочу развить идеи, которые у меня есть для приложения.

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

Но теперь я полностью потерян с Jsonwebtoken икак точно использовать его для того, чтобы сделать что-то безопасное и удобное для пользователя.

До сих пор я понимаю, что оставшийся API должен быть без сохранения состояния (т. е. ничто не должно быть хранилищем на стороне сервера и поэтому не должно иметь БДпризывает - как для сеансов - предоставлять доступ к данным).

В этом отношении я отметил различные стратегии:

• Краткосрочный JWT: (+)это очень безопасно, так как теоретически вам нужно входить в систему каждый раз, когда вы хотите получить доступ к серверу (-) очень плохой пользовательский опыт

• Долгоживущий JWT: (+) удобный для пользователя (постоянный вход) (-) очень вбезопасный (невозможно проверить, был ли украден JWT)

• недолговечный JWT с долгоживущим токеном обновления ...

Вот где я получаюпутать ...

Из всех прочитанных мной статей / руководств токен обновления должен быть каким-либо образом связан с БД (например, для хранения ключа токена обновления или токена в черном списке ...).Я также видел учебник, который частично связывал секретный ключ (для проверки токена) с хешированным паролем, хранящимся в БД.Это довольно умно, так как предыдущий токен будет автоматически считаться недействительным с того момента, как пользователь меняет свой пароль ... Но это еще раз означает, что вызов БД ...

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

И, учитывая этот вывод, я определенноЯ не могу понять, как использовать токен обновления…

Если для токенов обновления требуются вызовы БД, вы можете получить тот же результат только с одним основным токеном…

Вы можете, например, сохранить идентификатор JWTв токене и в БД ... Если эти два идентификатора совпадают при проверке токена, вы выпускаете новый токен с новым идентификатором, который перезаписывает предыдущий ... Теперь, если вы используете старый, он никогда не будет проверен ... Затем,так как вы вызвали БД для проверки токена (скорее всего, таблицы USER), вы можете проверить в то же время, если,например, пользователь является администратором или нет (нет необходимости хранить его в JWT)… Наконец, вы можете использовать описанный выше прием «хешированный пароль» для повышения безопасности…

Итак… Чего мне не хватает?Какова лучшая стратегия?

Я буду рад получить ваши комментарии по этому поводу (или ссылку на очень хорошую статью - хотя у меня их много…)

СпасибоВы очень за вашу помощь

PS: и я даже не говорю о том, как отправить токен на сервер (с cookie, но с риском присоединения CSRF или с заголовком, но подвергается атаке XSS, если токен хранитсяна стороне клиента)… В этом отношении я видел несколько обучающих программ, в которых используется JWT через cookie с сохранением клиентского ключа cerf на стороне клиента, а также внутри jet => оба должны быть отправлены.

PS2: надеюсь, я 'Я ясно, так как я говорю по-французски: -)

Answer 1

Итак, вы задали немало вопросов в этом одном вопросе.Кому-то здесь будет сложно дать вдумчивый ответ, но я постараюсь.До этого, полный отказ от ответственности, что я являюсь автором новой библиотеки SuperTokens, которая, я считаю, предоставит вам лучшее решение для управления сессиями.Возможно, вы уже читали наш блог: https://hackernoon.com/all-you-need-to-know-about-user-session-security-ee5245e6bdad. Лучше всего, если мы поговорим об этом, чтобы я мог дать вам подробное объяснение всего, что вы просили (я бы хотел помочь).Присоединяйтесь к нашему раздору: https://discord.gg/zVcVeev

Теперь, чтобы ответить на ваши вопросы:

• Вы всегда должны использовать только кратковременные JWT

• Выполнение вызова базы данных для аутентификации не является проблемой, но, как и все остальное, мы стараемся оптимизировать вещи, поэтому лучше делать меньше вызовов БД.Если вы используете токены доступа JWT и Opaque Refresh, то для большинства API вам не нужно делать вызов db.Тем не менее, если вы связываете секретный ключ JWT с хешированным паролем, то вам потребуется вызов db для каждого API - это нормально, но я чувствую себя ненужным, поскольку вы все равно собираетесь использовать недолговечные JWT (несколько часовдо дня максимум)

• Вы упомянули о краже токена - это сложная проблема, но в соответствии с RFC 6819 вы можете использовать концепцию вращения токена обновления для обнаружения кражи.Конечно, на самом деле это может быть непросто, так как вам нужно позаботиться о многих условиях гонки и проблемах с сетью - см. https://hackernoon.com/the-best-way-to-securely-manage-user-sessions-91f27eeef460

• О том, почему нам нужны токены обновления: скажем, у вас нетобновить токен, тогда у вас будет только один токен, который вы можете рассматривать как токен доступа и обновления.Вы все еще можете сделать его недолговечным (когда это токен доступа), а затем, после его истечения, обработать его как токен обновления - который также имеет некоторое время жизни.Проблема в том, что он не очень чистый (суть истечения срока действия токена в том, что он бесполезен впоследствии), и что вы выставляете токен обновления по сети при каждом вызове API - это снижает безопасность.Я знаю, что у вас может быть HTTPS, но есть и атаки HTTPS MITM - см. Пост в блоге, часть 1.

• С точки зрения хранилища, одним из хитрых приемов может быть разделение доступатокен на две части - одну для хранения в безопасных файлах cookie httponly и одну для хранения в локальном хранилище.Для каждого вызова API отправляйте оба на сервер (куки-файлы будут отправляться автоматически в любом случае), а затем сервер объединит их и приступит к аутентификации.Это предотвратит как CSRF, так и XSS атаки на сеансы!

Теперь вы можете реализовать все это самостоятельно или использовать нашу библиотеку, которая делает все эти вещи изbox: https://github.com/supertokens/supertokens-node-mysql-ref-jwt.

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

PS: я знаю, что использовал это для рекламы своей библиотеки, ноЯ надеюсь, что я ответил на ваш вопрос.Действительно трудно дать хорошее объяснение своим вопросам без разговора.