Я учусь программировать уже год. В основном я научился работать с остальным API (Node/Express на бэкенде и Vue на фронтенде).
Я дошел до того, что хочу развить идеи, которые у меня есть для приложения.
Для этого я сначала хотел разработать серверную часть, чтобы иметь процесс аутентификации, который я мог бы использовать в качестве шаблона для другого проекта, который у меня был бы.
Но теперь я полностью потерялся в Jsonwebtoken и в том, как именно его использовать, чтобы сделать что-то безопасным и удобным для пользователя.
До сих пор я понимаю, что API для отдыха должен быть без гражданства (т.е. ничего не должно храниться на стороне сервера и, следовательно, не должно иметь вызовов БД - как и для сеансов - для предоставления доступа к данным).
В этом отношении я отметил разные стратегии:
Недолговечный JWT: (+) это очень безопасно, поскольку теоретически вам нужно входить в систему каждый раз, когда вы хотите получить доступ к серверу (-) очень плохой пользовательский интерфейс
Долгоживущий JWT: (+) удобный для пользователя (постоянный вход в систему) (-) очень небезопасный (нет возможности проверить, был ли JWT украден)
Недолговечный JWT с долгоживущим токеном обновления…
Вот я и путаюсь…
Из всех статей/учебников, которые я читал, токен обновления должен быть каким-то образом связан с БД (например, для хранения ключа токена обновления или токена из черного списка…). Я также видел учебник, который частично связывал секретный ключ (для проверки токена) с хешированным паролем, хранящимся в БД. Это довольно умно, так как предыдущий токен будет автоматически считаться недействительным с момента изменения пользователем своего пароля… Но это снова означает вызов БД…
Суть в том, что я прихожу к выводу, что (1) не существует идеального способа обработки процесса аутентификации безопасным и удобным для пользователя способом… (2) нельзя избежать вызовов БД, чтобы иметь что-то более безопасное…
И учитывая этот вывод, я определенно не могу понять использование токена обновления…
Если бы токены обновления требовали вызовов БД, вы могли бы получить тот же результат только с одним основным токеном…
Например, вы можете сохранить идентификатор JWT в токене и в БД... Если эти два идентификатора совпадают при проверке токена, вы выдаете новый токен с новым идентификатором, который перезаписывает предыдущий... Теперь, если вы используете старый, он никогда не будет проверен... Затем, поскольку вы вызвали БД для проверки токена (скорее всего, таблицы USER), вы можете одновременно проверить, является ли пользователь, например, администратором или нет (нет необходимости хранить его в JWT)… Наконец, вы можете использовать описанный выше трюк с «хешированием пароля» для повышения безопасности…
Итак… Что я упускаю? Какая лучшая стратегия?
Буду рад вашим комментариям по этому поводу (или ссылке на очень хорошую статью — хотя у меня их много…)
Большое спасибо за Вашу помощь
PS: и я даже не говорю о том, как отправить токен на сервер (с куки, но с риском присоединения CSRF или с заголовком, но с учетом XSS-атаки, если токен хранится на стороне клиента)… В этом отношении я видел несколько учебников, которые используют JWT через файл cookie с ключом cerf, хранящимся на стороне клиента, а также внутри самолета => оба должны быть отправлены.
PS2: Надеюсь, я понял, так как я франкоязычный :-)
